Live data from Hacker News

How much your computer can do in a second

computers-are-fast.github.io

51–60 of 244 posts

Re: How much your computer can do in a second

#51
post #49
post #41

Earlier quoted context omitted.

You can't really do loop unrolling and constant folding as some suggest because the number of iterations is determined at run time. But assuming his CPU takes one cycle for an addition and one cycle for a conditional jump, his CPU only needs to run at 1GHz to achieve his result. Given that branch prediction should be nearly perfect for such a simple and short loop, modern x86 CPUs doing at least 4 integer additions p…

> You can't really do loop unrolling and constant folding as some suggest because the number of iterations is determined at run time. Huh?

That question is a bit unspecific :D

>NUMBER = atoi(argv[1]);

argv is populated at runtime based on what the OS passed you.

But you are right if you meant that my statement is too strong: you can't do arbitrary loop unrolling. You can jump to a loop that's unrolled once if the number is even, etc.

There are certainly also optimizers that will just output the input without any loop, but that's beyond anything I would expect of a current production compiler.

Re: How much your computer can do in a second

#53
post #48

Earlier quoted context omitted.

What I was getting at is that the suggestions to add crap would come from the product manager candidate themselves - thereby "proving" (if the results match my prediction) that the requirement for slow unresponsive interfaces come directly from the PM's, who would add it if it weren't already slow. Like, I want the experiment to test if a product isn't already slow, would a product manager actively make it slow? (I t…

When software is too slow it hurts sales. When software lacks features that hurts sales too. Faster doesn't make for compelling marketing (anybody can claim their software is fast) but you can get people to upgrade for new features. So features are added with every release and performance improvements are made up so to the point where it's "good enough" again. You don't need a product manager conspiracy to explain wh…

Okay, so let's update the experiment protocol.

So the hypothesis is that if it's too fast it's not considered done by a product manager. So as an updated test protocol, let us repeat with two groups of Product Managers, and this time they must evaluate the software, which they have never used before. Some candidates get the older version on the metal, and others get the older version slowed down 10x for example by running in a VM on the test machine, or simply being shown to them running on older hardware but otherwise an identical setup.

My hypothesis is that the exact same software running slowly would be objectively judged as better by Product Managers than the same software running instantly. That instant execution is considered an explicit negative point - completely independent of features. So that if the old software running slowly gets 7.5/10 rating by the Product Managers asked to evauate it, it would get only a 5/10 rating if it runs instantly.

This controls for the features which you mention. So I've suggested a test protocol, of course I can't verify it just at this moment but at least I am being scientific in my suggestion that Product Managers simply rate fast software worse. If you have an alternative protocol to test this, one that is easier to run, I'd like to hear it.

Re: How much your computer can do in a second

#54
post #31

Earlier quoted context omitted.

So is there any way to stop this treadmill, short of overthrowing capitalism itself? Edit: If that seems like a non-sequitur, I said it because the parent comment started by saying that the market is wasteful.

There is certainly a case to be made for overthrowing capitalism, but I don't see why an anti-capitalist revolution would automatically result in a society with higher quality software. Open source software suffers from much the same problems as commercial software. There is much about writing good software we haven't figured out how to do yet as an industry, and in the meantime we have to work with tools that are to…

Why do you think our tools are inadequate? What would adequate tools be able to do that our current ones can't?

Re: How much your computer can do in a second

#55
post #34

Earlier quoted context omitted.

To be fair, that article is discussing a small bug, not over engineering or dogma. The size of the deal people made over it was more wasteful than the CPU time this (now fixed) bug cost. And FWIW, of all the problems that matter to me and my teams, I find premature optimization to be far, far more wasteful of money and human energy than wasted CPU cycles. There are definitely times to worry about performance, and I f…

>I find premature optimization to be far, far more wasteful of money and human energy than wasted CPU cycles. I would argue this always depends upon what you're doing. For example, in webdev, the culture of prototype fast and break things fast is very abundant, and makes sense when you're just trying to figure out if what you want done is even possible. However, there are many times where you /do/ have to consider th…

> some of the ES6 goodies, like 'let', are actually bad practice... 3x slower than using var

This is good to know! I suspected, but never verified. I assume this will get fixed over time, since 'let' is brand new.

But JavaScript in general isn't well suited to image filtering, right? Certainly worth using, if at all possible, either CSS filtering or WebGL. Either of those will be much faster. Depending on what you're doing, some complex filtering operations will even be faster to upload to a back-end, process, and download the result. :P Is WebGL something you avoided because it won't work for you, or something you avoided because it's more costly development wise?

Hey overall, I agree with everything you say, and I'm still comfortable saying, dogmatically, never optimize prematurely. What that means to me is don't do engineering for problems you don't know you have. If you're not sure, then you don't know. If you're doing filtering, and napkin math proves in advance that you can't beat 5fps and your requirements call for 15 fps, then you do know.

In my mind this even fits with startups, because a startup's mission is to find the product and market, to figure out what's possible and then execute on it.

So ultimately I agree 100% it always depends on what you're doing, my additional caveat is always know what you're doing. :)

Re: How much your computer can do in a second

#56
post #22

Yes, modern computers are fast. How fast? The speed of light is about 300,000 km/s. That translates to roughly 1 ns per foot (yeah, I mix up my units... I'm Canadian...) THUS, a computer with a clock speed of 2 GHz will be able to execute, on a single core/thread, about 4 (four !) single-clock instructions between the moment photons leave your screen, and the moment they arrive into your eye 2 feet (roughly) later. _…

Most modern CPU's can execute more than one instruction per clock cycle on a single core or hardware thread. They do a lot more than 4 instructions in the time light can travel 2 feet.

Re: How much your computer can do in a second

#58
post #34

Alternatively, this could be titled "do you know how much your computer could do in a second but isn't because of bad design choices, overengineered bloated systems, and dogmatic adherence to the 'premature optimisation' myth?" Computers are fast, but not if all that speed is wasted. A recent related article: https://news.ycombinator.com/item?id=13940014

To be fair, that article is discussing a small bug, not over engineering or dogma. The size of the deal people made over it was more wasteful than the CPU time this (now fixed) bug cost. And FWIW, of all the problems that matter to me and my teams, I find premature optimization to be far, far more wasteful of money and human energy than wasted CPU cycles. There are definitely times to worry about performance, and I f…

By definition an optimization being premature means it's not necessary in the present. For these situations its like taking a loan for technical debt. In the future you may need 10x the resources to fix but in many environments that's acceptable due to company growth, or like you mentioned, spending money on compute rather then Dev time.

That said, I've been amazed what the top engineers in the field can design and implement getting things right the first time without additional effort. Simple, minimalist, high performance implementations that don't sacrifice much. There is a thin line between the beauty of those architectures and grab bag of pattern matching complex and unecessary optimizations.

Re: How much your computer can do in a second

#59
post #22

Yes, modern computers are fast. How fast? The speed of light is about 300,000 km/s. That translates to roughly 1 ns per foot (yeah, I mix up my units... I'm Canadian...) THUS, a computer with a clock speed of 2 GHz will be able to execute, on a single core/thread, about 4 (four !) single-clock instructions between the moment photons leave your screen, and the moment they arrive into your eye 2 feet (roughly) later. _…

Most modern CPU's can execute more than one instruction per clock cycle on a single core or hardware thread. They do a lot more than 4 instructions in the time light can travel 2 feet.

Also: While SIMD does not execute additional instructions, it executes more operations [that's the whole point; it reduces contention and bandwidth needs in the frontend / instruction decoding and scheduling]. A Haswell core peaks at 32 SP FLOP/cycle, for example.

Re: How much your computer can do in a second

#60
post #34

Earlier quoted context omitted.

To be fair, that article is discussing a small bug, not over engineering or dogma. The size of the deal people made over it was more wasteful than the CPU time this (now fixed) bug cost. And FWIW, of all the problems that matter to me and my teams, I find premature optimization to be far, far more wasteful of money and human energy than wasted CPU cycles. There are definitely times to worry about performance, and I f…

>I find premature optimization to be far, far more wasteful of money and human energy than wasted CPU cycles. I would argue this always depends upon what you're doing. For example, in webdev, the culture of prototype fast and break things fast is very abundant, and makes sense when you're just trying to figure out if what you want done is even possible. However, there are many times where you /do/ have to consider th…

> ES6 goodies, like 'let', are actually bad practice...

BTW, this is a really good example of why people like to avoid premature optimization.

Performance oriented code frequently has to break all the rules, it often goes against all "best practices" for code that isn't performance critical. If you do it too early, you will wreck your codebase's ability to deal with 1- non performance critical code and 2- other performance issues than the one you solved.

If you make it a rule to avoid using 'let' everywhere, then you lose the safety mechanism of block scope variables, something that a lot of people agree is a good idea.

It's very easy when you find out that let is 3x slower to stop using let, but then if you do that you're prematurely optimizing everything. And if you don't do it, everything you write is a little slower than it could be, and that will nag at you.

Functional programming is another good example of what many many people consider a good idea for code safety, and yet it is frequently abysmal for performance. Just to use another JavaScript example... using map() has historically been about 10x slower than using a for loop.

The singularly smartest engineer I know, who's now managing a huge team at NVIDIA, said to me that engineering for features is a solved problem, but engineering for performance is an unsolved problem. We know how to do class hierarchies and architecture and pub-sub systems to make a 10M LOC application manageable. We don't know how to write high performance code on that scale.

Post reply on HN