On Tue, Jul 09, 2019 at 11:11:23PM +0100, Ken Moffat via blfs-dev wrote: > I've now completed a real "tuning" run of my experiment (i.e. > specifying -falign-functions=32 -malign-data=cacheline because these > have been said to be beneficial for haswell processors, which is > what I have been using. >
I've now completed the final runs of this set of tests. The primary focus was on using -O3 throughout, but then I backtracked and tried detuning binutils and gcc back to -O2 (no benefit, everything slower). But along the way I decided that I needed more runtime tests. The source for those is now included (although not media files which I cannot share). When using -O3, there are additional failures in ld's tests because what the testsuite is looking for has been optimized out. There was also an intermittent failure in coreutils : I think this is down to a race. Beyond that, -O3 is generally beneficial, although not by much. For texlive, it appears that using -O2 instead of -O3 leads to faster builds (including the testsuite) and to slightly faster runs of traditional latex. And for rust I conclude that there is no practical difference between optimization levels of 2 and 3. Details in http://www.linuxfromscratch.org/~ken/tuning/ There is a *lot* of runtime variation when running repeated tests, and ostensibly similar-or-slower builds can be faster. This makes me think that ALL runtime test results on non-rt linux should be treated with suspicion! But for me, on a desktop using the cheap hardening options, -march=native (with the proviso that such as system can only build for upward-compaible machines) and mostly -O3 seems the way to go. ĸen -- One pill makes you larger, And one pill makes you small. And the ones that mother gives you, Don't do anything at all. Go ask Alice, When she's ten feet tall. -- Jefferson Airplane, White Rabbit -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
