-O3 is too smart, it optimizes away the loop and transforms the code into printf(the_result).

Hah, nice. Didn't check the resulting code. Know what the other optimization levels do? I'm don't really know x86 assembler.

I do still side with the optimization though, in that the .NET-VM could do this as well. The loop is pretty simple, and can be optimized away. Why shouldn't it?

Your answer received lots of votes for what are basically assumptions.

The author of the article updated his post for -O3 by using a volatile variable for the for-loop test, which makes the compiler not optimize away the loop.

For .NET you can look at the generated assembly, and if it does optimize away the loop you can use the same trick.

No reasons for guessing. We are software engineers after all.

"volatile" forces the C compiler to issue load and store instructions for each access (although real-world C compilers are notoriously buggy here), so it makes the loop much slower. That's not a fair comparison.

He wasn't trying to write something faster than C, he was just establishing a good baseline. He makes that clear in the article when he specifically addresses the fact that compiling with optimizations removes the loops.

(I wonder, did the people who upvoted you actually read the article?)

Did you miss the "update" part? That was at least a few hours after my post. And, despite using volatile, it still runs faster.

Apologies on the first results, simvm.c had mistakenly not compiled, so those were the original loops. I had to modify the code to get it to compile (dropped it to "#define LONG") and here are the results:

  real	0m2.209s
  user	0m2.191s
  sys	0m0.006s

vs

  real	0m0.020s
  user	0m0.001s
  sys	0m0.003s

assembly code for gcc -O3 -S simvm.c: https://gist.github.com/710249

Where's the printf(answer)? For comparison, here's the `gcc -S simvm.c` output: https://gist.github.com/710269