| >I think it's 'common knowledge' which has outlived it's relevance as I can't recall the last time I found -O2 outperforming -O3. I can, was about 4 months ago with GCC 4.8.0. >practically every performance oriented open source program I come across also defaults to -O3 these days How large is your sample size there? I have only seen -O3 in the default makefiles of audio/video encoders. Those tend to be a natural fit for -O3. In contrast, here is the current makefile of my favorite "performance oriented" FOSS program: http://repo.or.cz/w/luajit-2.0.git/blob_plain/HEAD:/src/Make... CCOPT= -O2 -fomit-frame-pointer
# Note: it's no longer recommended to use -O3 with GCC 4.x.
# The I-Cache bloat usually outweighs the benefits from aggressive inlining.
>I can't recall any loop unrolling options which are turned on at -O3. You are right (I just looked it up). Guess my memory failed me there. >I'd say they typically use the upstream optimization settings I wish! Packagers love to fool around with the upstream sources and makefiles to make them conform to whatever "standards" they have. |
Well I very much implied 'performance-oriented' programs as we where discussing 'performance' generated by compiler options, which indeed are a natural fit for -O3.
For which my 'sample size' would be software like encoders, archivers, emulators, 3d renderers etc.
Obviously there's little point in using -O3 on your text editor (yes, extreme example), basically for any non performance-oriented software -O3 will likely only serve to increase the binary size as any potential gains will be unnoticable.
>I wish! Packagers love to fool around with the upstream sources and makefiles to make them conform to whatever "standards" they have.
Not really my experience with Arch packages, but of course I haven't looked at the PKGBUILDS for even 1% of all available packages, basically only those performance oriented packages on which I rely.