Live data from Hacker News

The computers are fast, but you don't know it

shvbsle.in

791–800 of 819 posts

Re: The computers are fast, but you don't know it

#791
post #770

While I find this comment section fascinating and will read it top to bottom, I can't help but make an observation that such articles often comply with: +-------------------------------------------------+ | People really do love Python to death, do they? | +-------------------------------------------------+ I find that extremely weird. As a bystander who never relied on Python for anything important, and as a person…

Completely agree that objectively, Python has really bad underlying tech. Emotionally though (once you have the environment set up), it’s just such a breeze to write it. It’s like executable pseudo code with zero boilerplate. You can focus purely on the algorithms and business logic. Compared to many other languages the line count is often 50-80%, even if you include type annotations! This doesn’t only apply to plain…

> Emotionally though (once you have the environment set up), it’s just such a breeze to write it.

That's no different than the JS fans saying "hey, if you have the exactly right versions combo of Node.JS, npm and webpack, everything works fine!". I almost never manage to install anything via `pip install`. I just cross my fingers and am not at all surprised when it doesn't work. Not for a lack of trying, mind you, I've fiddled with separating Python 2 and 3 environments, tried a few package managers etc.

If I can't install Python + a package manager and I can't then install any random tool that proudly says "we're just a `pip install` away" in their GitHub repo then to me that's a failed ecosystem relying on inertia and Stockholm Syndrome. ¯\_(ツ)_/¯

> It’s like executable pseudo code with zero boilerplate.

Is it? I've seen some pretty horrible constructor boilerplate that managed to look almost as alien as Perl. Also who decided that methods starting by underscores is a solid convention lol. Of course bad programmers will manage to butcher every language, think we all agree on that, but as I get older I appreciate languages that don't allow bad coding in the first place (or realistically, limit it as much as they can).

> You can focus purely on the algorithms and business logic.

Not my observation. I know a few data scientists and a few people who just learned Python out of desperation related to how mundane and repetitive their jobs are. They all had to wrestle with OS-specific quirks -- that a stdlib absolutely should abstract away -- the same package management woes as me, and libraries they need subtly breaking because apparently they only work well in Python 3.6 and not after (one random example).

I get the sentiment and I wanted to believe that such a language existed a while ago but I am just not seeing it. Foot-guns and all, you know the old sayings.

> For many applications where the the outcome of the program is more important than the performance or environment, like glue code, simple intranet applications or exploratory coding, it is still the perfect choice.

I am still looking for such a tech for myself as well because my main choices of languages aren't a super good fit for tinkering. But so far I haven't seen Python filling that niche. Too much minutiae to handle.

> You also have to consider what it is replacing, often the alternative would be even worse; bash-scripts, Excel or Matlab.

Yeah that's a real problem, absolutely. For now I always got away by just learning an insane amount of CLI / TUI tools and always assembling them together just enough with bash/zsh scripting to get my task done... but that approach has deficiencies as well, and will not work forever.

> Another way to put it is that it’s a very good Swiss Army knife that is good at everything but not best at anything.

To add to the analogy: it also starts getting rusty and doesn't work as reliably as before but grandpa will let anyone replacing it only over his dead body.

(And I semi-mockingly call people "grandpas" as a 42 year old who is supposed to be conservative but I find it extremely amusing how many 28-year olds I've met that are more conservative than me and my 69-year old mother.)

Re: The computers are fast, but you don't know it

#792
post #790

Earlier quoted context omitted.

You cannot call a method on null. Meaning: - Practically, Java would rather have to `return 3` when it detects a null child, effectively precomputing the penultimate level. - Semantically, Java could no longer distinguish between an absent child and a child with no children. Honestly, I have other variants that still don't use pooling but are less idiomatic; I find this exercise is begging the question hard. Any tool…

I think you just said the Java etc programs could be re-written in a similar way? And we could add some more rules ("distinguish between an absent child and a child with no children") to reject those Java etc programs.

> I think you just said the Java etc programs could be re-written in a similar way?

I could rewrite the Go program to return 3 too, but I doubt you’d accept that.

I can only conclude the benchmarks game is bad-faith bullshit at this point.

Re: The computers are fast, but you don't know it

#793

Earlier quoted context omitted.

I'm on an M1 Air (cheapest base model), and I use it largely for writing (also dev but I get that that's not your question). - For native M1 apps like Pages, Sublime, or Highland there's no lag at all. For example, with Highland 2 from double-clicking a file to editing it is less than a second and there's no lag during use even with a 49,000 word book manuscript open. - For x86 apps like the not-quite-latest Office t…

That's very good to hear, I've been looking at MacBook Air also because they're pretty much the kings when it comes to battery life for a handbag sized laptop. I think the bidder MacBooks have slightly better battery, but you can't really fit those in a smaller bag, you do kinda need a backpack for it or a laptop specific bag.

> I've been looking at MacBook Air also because they're pretty much the kings when it comes to battery life for a handbag sized laptop.

Battery life is, indeed, impressive.

Last night I spent around 5 hours doing C# dev in VS Mac, with multiple projects being built every few minutes, cross-platform binaries for Intel Mac, Windows, and Linux being produced every half hour or so, plus Highland 2, Word 2016, and Vellum. With all that it used 28% battery across that 5 hours (and never got warm). On full brightness too (for my sins).

I know the question isn't about dev, but writing uses less resources and gives even better battery life so 18 hours (for example) is definitely possible.

The only issue I have is the keyboard. Far better than the 'broken' ones of a few years ago but I really wish they'd go for thicker machines and increase the travel. I've just got rid of my last ThinkPad and it's the one thing I miss.

Oh, and there is no longer a hotkey to control the backlight brightness; it's automatic. Which genuinely works perfectly except that it doesn't come on for your very first sign in at boot-up, so entering your password then can be tricky without ambient light (though after that you can use the fingerprint reader). It's a really strange UX flaw. Not related to your question, I know, but you don't say whether you're already on a Mac or switching so I wanted to be honest about this as it is really annoying but rarely mentioned.

Re: The computers are fast, but you don't know it

#794

Earlier quoted context omitted.

Sorry, I dropped all the 1s in that message when i typed it (laptop keyboard is a little sketchy right now). That should have been 15 and 18. I think the recent Intel microarchs take 14 plus howewever long at uopd decoding that minimum 1, so 15-20 or close to that. > The dependency chain length is what is normally intended as instruction latency. Yes, the way I read the original post and others was that you actually…

> Sorry, I dropped all the 1s in that message when i typed it It makes sense now! :D > You're not getting a result in less than 20 cycles basically But the end of the pipeline is an arbitrary point. It will take a few more cycles to get to L1 (when it makes it out of the write buffer), a few tens more to traverse the L2 and L3 and hundreds to get to RAM (if it gets there at all). If it has to get to an human it will…

> which is indeed 3-5 cycles depending to the specific microarchitecture

I assume you are talking about from fetch to hitting the store buffer? That would be the aabsolute min time before the data could be seen elsehwere I would think. It can still potentially be rolled back, and that would be higher than reciprocal be way too fast to sustain, but for a single instr burst, I'm not sure. So much happens at the same time, An L1 read hit will cost you 4 minimum, hut all but 1 of that is hidden. can't avoid the multi cost of 3 or add 1. the decoding and uop cache hit, reservation, etc will cost a few. I have no idea.

If you know of anything describing it in such detail, I would be comopletely curiouis.

Re: The computers are fast, but you don't know it

#795

Earlier quoted context omitted.

Just like freeways - add more traffic lanes, get more traffic.

Theres actually a name for that phenomenon: Braess’ Paradox https://en.wikipedia.org/wiki/Braess%27s_paradox

Though it's only a paradox for a small number of additional lanes. If 100 lanes are added then traffic will speed up.

Re: The computers are fast, but you don't know it

#796
post #790

Earlier quoted context omitted.

I think you just said the Java etc programs could be re-written in a similar way? And we could add some more rules ("distinguish between an absent child and a child with no children") to reject those Java etc programs.

> I think you just said the Java etc programs could be re-written in a similar way? I could rewrite the Go program to return 3 too, but I doubt you’d accept that. I can only conclude the benchmarks game is bad-faith bullshit at this point.

> … bad-faith bullshit…

Kudos for actually bothering to "read the rules".

None for ignoring what you read.

The answer to "… but if my language lets me not allocate a node yet still use that node why should I?" is — Because allocate a node is the basis of comparison with the other programs!

Change that for the Go programs and you change that for all the other programs; otherwise just special pleading for Go lang.

Re: The computers are fast, but you don't know it

#797

Earlier quoted context omitted.

Channel arrows are basically just read/write operations. If `ch` is a channel, then this expression means "value obtained from reading from the channel": And this expression means "write value x into the channel": ch Both expressions can be used as a case inside select statement: select { case val := Which will execute exactly one case, depending on which channel becomes "ready" first - channel is ready for reading i…

It was a rhetorical question.

So you were trolling. Bummer.

Re: The computers are fast, but you don't know it

#798
post #796

Earlier quoted context omitted.

> I think you just said the Java etc programs could be re-written in a similar way? I could rewrite the Go program to return 3 too, but I doubt you’d accept that. I can only conclude the benchmarks game is bad-faith bullshit at this point.

> … bad-faith bullshit… Kudos for actually bothering to "read the rules". None for ignoring what you read. The answer to "… but if my language lets me not allocate a node yet still use that node why should I?" is — Because allocate a node is the basis of comparison with the other programs! Change that for the Go programs and you change that for all the other programs; otherwise just special pleading for Go lang.

[deleted]

Re: The computers are fast, but you don't know it

#799

As a front-end developer, I can't help but notice how much useless computation is going on in a fairly popular library - Redux. It's a store of items, if just one tiny items change in the whole store, every subscriber of every item gets notified and a compare function is ran to check if it changes. Perhaps I'm misunderstanding something and not to bash on Redux - I'm sure there are well-deserved reasons it got popula…

Redux is not a new pattern. The pattern is many decades old. The reason we use it now is because computers have become fast enough that it's okay now. Nobody thinks this is a performant pattern; it's only "new" because of how terrible the performance is. This is offset by how easy it is to use. All of this also applies to React and Vue.

Re: The computers are fast, but you don't know it

#800
post #392

Article says at one point, "We have reduced the time for the computation by ~119%!", which is impossible. If you reduce it by 100% it is taking zero time already.

People like to talk in percentages when it's obviously unclear what it means, and they frequently get it wrong. It gets even better when people start switching between percentages and "percentage points" referring to a measure that's in percentages originally. Unfortunately, most of those things are easier communicated and harder to get wrong if you try speaking in a more natural way. This is now "twice as fast" or "…

I like to write "Takes X% of the time it took before" for maximum disambiguation
Post reply on HN