Beating the Compiler
codersnotes.com
Beating the Compiler
1–10 of 89 posts
Re: Beating the Compiler
#2Intel and AMD publish programming guides that would help you producing more optimized code.
Then there are some aspects that compilers might not optimize a lot for. I like this guide: http://www.farbrausch.com/~fg/seminars/lightspeed_download.p...
It's old, dated, whatever you want, but covers the basics.
edit: it seems that link got the "HN hug of death".
Re: Beating the Compiler
#3Bestcase seems like a poor metric when the CPU scheduler could certainly cause 7% variation. I would be interested to see, say, 100x the number of runs, and see mean rather than best, since one usually cares about average more than best.
I also wish I knew what optimization settings GCC/etc was using, and what effect tweaking those has.
Re: Beating the Compiler
#4Bestcase seems like a poor metric when the CPU scheduler could certainly cause 7% variation. I would be interested to see, say, 100x the number of runs, and see mean rather than best, since one usually cares about average more than best. I also wish I knew what optimization settings GCC/etc was using, and what effect tweaking those has.
> I also wish I knew what optimization settings GCC/etc was using, and what effect tweaking those has.
From the makefile:
GCCFLAGS = -O3 --std=c++11
MSFLAGS = /nologo /Ox /Ob2 /Ot /Oi /GL
Re: Beating the Compiler
#5This seems quite ridiculous to me, I have seldom seen "modern compilers are always faster than you" but rather "they are good enough that it is not worth it". It provides a very over-confident "conclusion" based on a single dubious test.
The main advantage of compilers is that the optimizations scale across a large codebase through inlining for example.
Also, just moving from Sandy-Bridge to Haswell for example can have significant performance swing (in both direction). The maintenance cost of the assembly is again a scaling issue.
If you have a single function that takes a significant amount of time in your program, and performance is critical, of course you can try to go with lower level. But it is likely that it will be more profitable to start with 1) pre-optimized libraries (i.e. don't write your own "sort") ; 2) follow the optimization guidelines of the CPU vendors regarding memory layout, etc. ; and 3) start with vector C-level intrinsic if possible if you can benefit from vectorization.
Re: Beating the Compiler
#6Bestcase seems like a poor metric when the CPU scheduler could certainly cause 7% variation. I would be interested to see, say, 100x the number of runs, and see mean rather than best, since one usually cares about average more than best. I also wish I knew what optimization settings GCC/etc was using, and what effect tweaking those has.
The timing _should_ be constant each run, so best case is the best way to remove the scheduler variations. I tried mean also, and the results aren't that different.
Optimization is -O3 (see the attached Makefile at the bottom).
Re: Beating the Compiler
#7Bestcase seems like a poor metric when the CPU scheduler could certainly cause 7% variation. I would be interested to see, say, 100x the number of runs, and see mean rather than best, since one usually cares about average more than best. I also wish I knew what optimization settings GCC/etc was using, and what effect tweaking those has.
Because of noise in general, "best case" seems always like the best metric to me. Over a large number of run, you're likely to hit the "perfect" measurement with on a microbenchmark.
Otherwise, for an "adaptive" number of runs till enough time is spent to have some "confidence" on the measure, I've been fairly happy with: https://github.com/google/benchmark/
Re: Beating the Compiler
#8I'm just curious if there is any overhead in the compiler outputs as the author seemed to be timing the .exe
It would be interesting to see the assembly output of all the compilers, and what the compiler settings are
Re: Beating the Compiler
#9I'm just curious if there is any overhead in the compiler outputs as the author seemed to be timing the .exe It would be interesting to see the assembly output of all the compilers, and what the compiler settings are
The timing happens directly around the function itself inside the EXE.
Compiler settings are in the makefile, full optimization (-O3 or /Ox)
Re: Beating the Compiler
#10why the best-case was chosen instead of mean or median?