3 ms·
Have you timed this? Instruction caches are finite, and overflowing them hurts performance so badly that some more loop unrolling may not help.
by 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 agoI'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 agoThis 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.