3 ms·

He specifically asked gcc for optimisation for code size (-Os). For speed, he should be using -O3 only. He used "-Os -O3". This invalidates the benchmark.

• JoachimSchipper 16y ago
  Have you timed this? Instruction caches are finite, and overflowing them hurts performance so badly that some more loop unrolling may not help.
  • rlpb 16y ago
    I've not timed anything, but asking gcc to optimise for size is the wrong thing to do when benchmarking for speed. I can think of lots of ways that this would cripple performance. Why not let gcc make its own decision? The only justification for using -Os in a speed benchmark is "I tried it both with and without the flag, and it was faster this way". I don't see any such assertion.
    • deleted 16y ago
      [deleted]
    • gwern 16y ago
      > The only justification for using -Os in a speed benchmark is "I tried it both with and without the flag, and it was faster this way". I don't see any such assertion. Really? It seems to me that this is quite enough: > I’ve just re-run the C benchmark without -Os (only -O3) but the results are the same.
  • Tuna-Fish 16y ago
    This is true for real software, not microbenchmarks. All of the shootout benchmarks will fit in their entirety in L1i cache -- which makes reducing the executable size pointless. Incidentally, this is probably the largest reason why so many people still use -O3 -- it wins in exactly the kind of programs that are used as simple and common benchmarks. It solidly loses on almost everything else.
    • deleted 16y ago
      [deleted]
    • adrianN 16y ago
      > It solidly loses on almost everything else. Do you have any data on that? Most CPU bound programs should have pretty good instruction locality, negating the effects of smaller code. But without some numbers this is pointless guesswork.
• regularfry 16y ago
  Apparently not: http://lbolla.wordpress.com/2010/12/05/sbcl-quicker-than-c/#comment-7809 http://lbolla.wordpress.com/2010/12/05/sbcl-quicker-than-c/#...
  • rlpb 16y ago
    If this holds true, I'll concede this specific point. As we know, however, benchmarking can often come down to tuning. If this most basic of compiler options has not been set to the obvious choice for speed, how can we have any confidence that the C code as written is written in an efficient way? Are we comparing language against language here, or somebody's implementation in one language against somebody's implementation in another? I note that there appear to be hand optimisations in the C code. Were these done well, or would the compiler have done a better job?
    • Someone 16y ago
      Of course we are comparing implementations; languages do not have a speed. My language (purely hypothetical, unfortunately) language at builds on 'Principia Mathematica' may need a 10000 page program to compute 1+1, but its compiler could, in theory, produce the same executable as C (or Fortran, or whatever) would from their one-liners that do the same thing.
• MtL 16y ago
  There is no difference at all, since the latter takes precedence (read the man pages): $ gcc -c -Q -Os -O3 --help=optimizers > Os-O3-opts $ gcc -c -Q -O3 --help=optimizers > O3-opts $ diff Os-O3-opts O3-opts $
  • rlpb 16y ago
    I didn't realise that. He actually uses -Os after -O3.