4 ms·
> Similarly, computer programs today are increasingly diverging into a state where there is a tiny amount of extremely performance critical code, and a large am
by Crito 12y ago
> Similarly, computer programs today are increasingly diverging into a state where there is a tiny amount of extremely performance critical code, and a large amount of code where performance is so good on our hardware today that even horribly unoptimized code has no noticeable effect on performance.
> Thus, optimizing compilers are useless on the first type of code (humans are better), and useless on the second (performance doesn't matter).
It seems to me that while speed may not matter much anymore, power consumption matters now more than ever before (the proliferation of computers that are run off of batteries). If you're computer spends less time running code and more time idle, even if we are talking about milliseconds that the end user won't use, you might use noticeably less power over the course of several hours.
The difference between "the phone ran out of power when I was still 5 minutes away from home" and "the phone ran out of power after I walked through the front door and kicked back for the evening" may be the difference between "the battery-life on this is shit, buy [competitors product]!" and "no complaints".
- ori_b 12y agoThe point is that all of the time spent running code is spent running only a small portion of code -- This is still case 1 listed above.
- deleted 12y ago[deleted]
- im3w1l 12y agoOne difference is that before only bursts needed to be super tight, now idle performance have to be in addition. Maybe his rule is still valid, but the two cases do seem a little bit different to me. Previously it used to be about optimizing that innermost loop that was only a few instructions long so it went twice as fast. A small local change with inline assembly. But idle behaviour involves architectural optimizations. Like pushing events instead of polling for them.
- ori_b 12y ago> now idle performance have to be in addition. Your idle time should be with all processes blocked in select()/poll()/epoll() and friends, and the CPU fully shut off with no code at all running. If your CPU isn't fully asleep -- if it's running instructions -- you've already lost. There was a bug with my cellphone where a service was holding a wakelock and preventing the CPU from shutting off. This was enough to drain enough power that it would drain even while on the charger.
- im3w1l 12y agoYeah, hopefully nobody busyloops ala for(;;)checkForEvent(); But I could see someone doing for(;;){checkForEvent();sleep(sometime);} or setInterval(checkForEvent, sometime); This wouldn't be terrible but not ideal.
- kragen 12y agoBernstein’s logic applies equally well to power consumption as to pure runtime.