Yes, the optimizer can take care of it some times, most of the time, ..., but phew!
While C compilers also generate pretty bad code when optimizations are off, it's nothing near this staggeringly awful. Unless you manage to write a longish loop that it can figure out, which is unlikely outside of benchmarks, my experience is you get around 2x or so for straight-line code that's pretty rare these days. This is 20x to 100x and more.
The 2x roughly matches Probsting's Law[1], which says that advances in compiler optimizer tech. double performance every 18 years. That's not a lot, and does not justify trusting the compiler this much. In short, making the semantics slow and trusting the sufficiently smart compiler [2] to fix it has never worked in the past, and I don't see any evidence why this time should be different.
Are you measuring a 20x slowdown with optimizations turned off? That's the only way I can reproduce your results. That's a completely meaningless comparison if so.
Yes, the optimizer can take care of it some times, most of the time, ..., but phew!
While C compilers also generate pretty bad code when optimizations are off, it's nothing near this staggeringly awful. Unless you manage to write a longish loop that it can figure out, which is unlikely outside of benchmarks, my experience is you get around 2x or so for straight-line code that's pretty rare these days. This is 20x to 100x and more.
The 2x roughly matches Probsting's Law[1], which says that advances in compiler optimizer tech. double performance every 18 years. That's not a lot, and does not justify trusting the compiler this much. In short, making the semantics slow and trusting the sufficiently smart compiler [2] to fix it has never worked in the past, and I don't see any evidence why this time should be different.
[1] http://www.cs.virginia.edu/~techrep/CS-2001-12.pdf
[2] http://c2.com/cgi/wiki?SufficientlySmartCompiler