Take game development for instance, if your code runs a bit faster that's more frames you're rendering per second. This can mean the difference between a laggy, unplayable mess and a good gaming experience on an average machine (a laptop, or a non-gaming rig).
Do we know that most new software runs in batteries? Do you have a reference for that? It would be useful.
Other question is - does a sleeping CPU always win, or are other optimisations such as memory usage, screen usage, and communications, more important? I know for sure that the CPU is not the main consumer of power on a bunch of Android phones that were used in an academic study.
Probably the CPU is not the main power sink on mobile devices (screen and radio are I think). But cranking up the optimization level is free for the developer.
It's not so simple. If you're trading off simplicity in the compiler for that speed,for example, it may be a net loss.
If speed was the only concern, we'd all go out and buy super computers.
You can optimise as much as you like but then John Q Madbugger comes along with their insane Javascript (not looking at Flickr here, no sir) and suddenly your performance is in the toilet.
Thinking over it some more, browsers themselves were probably not a good piece of software to call out on performance considering how much optimization is actually done to increase their performance. The horrid things people do on top of them deserve all the blame they get though, and then some.
I do however agree with underlying premise of this post: Code that works 100% of the time is better than higher performant code that explodes in your face every once in a while.
No they don't. Code size is rarely a problem (embedded probably cares..). Optimizations will in most cases lead to larger code, loop unrolling, inline expansion etc. In c the compiler cant't, in most cases do anything about memory usage. (Probably could pack structs.. , but that is not something the compiler would do I think, you would break ABI with non optimized code). In managed languages, memory usages is probably more depended on the runtime system GC, then compilers.
GCC has a flag for code size optimization -Os https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
"With -O, the compiler tries to reduce code size and execution time"
So actually yes, The compiler optimizes for both size AND speed. Sometimes you can optimize for maximum speed (-O3), and sometimes optimize for minimum code size (-Os). You can even optimize for best debugging or best compilation times, and forget about size/speed.
As for memory usage -
1. First of all - code uses up memory. smaller programs = less memory used for holding the exectuable code.
2. Consider the various ways you could compile a switch(-case) statement. You could build it as a set of conditional branches one after the other, you could compile it into a binary tree search (or a hash dictionary lookup), and you could jump to an address found in a lookup array table.
This former method is also called a "branch table". https://en.wikipedia.org/wiki/Branch_table
A branch table would be the fastest method for implementing a switch with a few sequential values (0,1,2,3,4,5) But would be a really bad idea for sparse values (0,200,5000,10000,200000).
Choosing not to use a branch table for sparse values is an optimization for Memory usage. And compilers make this decision all the time.
That depends. In game programming, if I had a choice between a render that will crash once every 10 hours and produce 60 fps (in some model envrionment) vs a render that never crashes but produces 45 fps, I would choose the first one.
Hell, I'd take a 1% chance of blowup for a 10% speedup any day.
Are you serious? Would you base your research career on software that you don't trust? I wouldn't.
Please, notice that 1% chance of full blowup means a not-null probability of nice-looking-but-actually-false results from time to time, and that's a risk no researcher is allowed to accept.
I guess you haven't seen the quality of academic code recently. The choices are basing your credibility on slow badly written code or fast badly written code.
Renting an extra server costs practically nothing comparing to wage costs for a tech company.
So I'd say they'd care more about the compiler being reliable and predictable.
I have a team that regularly generates savings of XX% of the entire datacenter CPU cycles of a very large fleet through better compiler optimization (that pretty much never breaks any of our programs. In fact, we break them more through almost anything other than better optimization. Shocking, i know, but you can test this stuff really well it turns out, and write sanitizers to find behavior you wouldn't discover at compile time and ...)
I know at least another 100 large companies where the cost savings of doing this kind of thing also totals in the tens to hundreds of millions, per year.
and that's just the normal X% a year, not the "we put a team of experts targeting your use case and they got you 100x" type of savings.
So yeah, there are people for whom this matters ... a lot, and dismissing them casually is not a great idea :)
Truthfully, IME, compiler-optimization induced bugs are so infrequent compared to normal you-wrote-really-wrong code bugs that IMHO it's missing the forest for the trees. (now, maybe people suck more at tracking them down, but ...)
Heck, I had once screwed up some code in GCC that caused it to essentially remove random stores and loads from the program being compiled. It only caused one visible failure across a bunch of real world apps that had serious validation suites.
From reading hacker news, you'd get the idea compiler optimizations follows your code down alleyways to mug it. In truth, people are so busy overflowing buffers and whatnot that we are lucky if we can break their code due to optimizing.
Performance gains of 1% just don't matter to most programmers.
This guy, what a fucking joke. Yeah to avoid bugs instead of using these fancy compilers (which rarely if ever are the cause of bugs) we should be assembling our programs by hand.
At some point, for extremely hot loops, there may be no choice but to write a few pages of assembly by hand. If this saves tens of thousands of lines of compiler code that doesn't generalize, and is used on thousands or millions of machines, it's worth it, IMO.
This is a strawman. The usual argument is that 1% better performance is, well, 1% better. That's a whole server if you have 100 servers. People are not desperate, but do want an additional server for free.
> Assuming that's true, then they should be crafting assembly code by hand.
This, and "a few cycles inside a loop", is another strawman. What usually happens is a good compiler saves a bit everywhere, which helps when the program is optimized to flat profile without hotspot. Since saving is everywhere, "crafting assembly" amounts to lots and lots of assembly, not just a few in strategic places.