Page 1 of 1
Funroll-loops
Posted: Mon Nov 05, 2007 11:06 pm
by solafidefarms
I know that funroll-loops is ricing, but I don't recall why -funroll-loops is bad. From what I read on the
gcc documentation page:
-funroll-loops
Unroll loops whose number of iterations can be determined at compile time or upon entry to the loop. -funroll-loops implies -frerun-cse-after-loop, -fweb and -frename-registers. It also turns on complete loop peeling (i.e. complete removal of loops with small constant number of iterations). This option makes code larger, and may or may not make it run faster.
Enabled with -fprofile-use
I don't see anything about it being unsafe. Has anyone successfully compiled their world with -funroll-loops, and given this info from the documentation, is it not unsafe to put it in my cflags?
Posted: Mon Nov 05, 2007 11:27 pm
by dnadesign
Yes, I don't see a reason either. It makes the code larger, thus making it more memory consuming, but still it can make it faster (but it's not a must). As for me: I currently don't use -funroll-loops and I can't say, that I'm suffering performence loss. Actually the system performance and latency have never been better.
Posted: Mon Nov 05, 2007 11:31 pm
by Akkara
Re: unsafe: This option is rarely used so it is more likely that there's a compiler bug lurking that slipped past testing.
Re: benefits: Seems questionable at best. A loop that is really run often might benefit. But few loops are that performance-critical. Many loops are initialization-code sections. Things like "zero out array". "Create table of sine values...". "Malloc a bunch of pointers-to-whatevers" Stuff like that. And all this option does is to bloat all those non-critical loops, making programs load slower, taking up more space in the cpu's cache which causes more memory fetches and generally only ends up slowing everything down.
The option is meant for that one really critical "the work is done here" file, that is specially compiled in the makefile with this option, while leaving it off the 90% of code that does setup and other ancillary stuff.
Posted: Mon Nov 05, 2007 11:51 pm
by i92guboj
As someone said above, it "usefulness" is -at least- questionable. It can be ok for a well known section of code, but I wouldn't set it globally to compile everything.
Posted: Tue Nov 06, 2007 10:11 am
by neuron
personally I would never build world with it, but I did modify the wine ebuild a while ago to use it, to see if it helped performance at all (and if I remember correctly, it didn't :p). If you need more performance out of one particular application, try it, but recompiling world with it will speed some things up, slow other things down, and might give you some cryptic problems later on.
Posted: Tue Nov 06, 2007 12:23 pm
by transient
Loop unrolling is one of those things that should be decided by the programmer (and sometimes the compiler), not by the end-user.
Posted: Tue Nov 06, 2007 11:52 pm
by beatryder
When I first started using Gentoo >2 years ago, I used it, once I recompiled without it, I didn't notice the difference in terms of the operating speed of the program, but task switching and loading was faster *without* funroll-loops.
Re: Funroll-loops
Posted: Wed Nov 07, 2007 1:59 pm
by unK
solafidefarms wrote:Has anyone successfully compiled their world with -funroll-loops, and given this info from the documentation, is it not unsafe to put it in my cflags?
Yes, I compiled whole world with these flags:
Code: Select all
-O2 -march=native -pipe -fomit-frame-pointer -fno-ident -funroll-loops -ftracer
And everything compiled fine with them. I did this because I was just curious about -funroll-loops and its influence on performance and actually I don't see any major difference (well, start of xorg-server takes about 1 extra second, to be honest). I didn't make any tests, so I won't say some programs are faster (although I feel so), because I don't know whether they are really faster. Only lame is faster for sure.
Re: Funroll-loops
Posted: Wed Nov 07, 2007 2:15 pm
by steveL
unK wrote:I didn't make any tests, so I won't say some programs are faster (although I feel so), because I don't know whether they are really faster. Only lame is faster for sure.
Interesting. It'd be good to [topic=499881]do this for individual apps[/topic], profile and tabulate the results.
Posted: Thu Nov 08, 2007 2:31 am
by mikegpitt
I don't think funroll-loops is 'ricing'. In fact, it is a very old static optimization technique. The real advantage comes in where by unrolling a loop the compiler may be able to better take advantage of additional optimizations. I used to run it for a long while, and fundementally I wouldn't consider it unsafe.
I personally think people make too big a deal about it bloating your executables, but I've never really looked to see the different base system size of a loop unrolled install vs not.
Posted: Thu Nov 08, 2007 3:16 am
by i92guboj
mikegpitt wrote:I don't think funroll-loops is 'ricing'. In fact, it is a very old static optimization technique. The real advantage comes in where by unrolling a loop the compiler may be able to better take advantage of additional optimizations. I used to run it for a long while, and fundementally I wouldn't consider it unsafe.
Most flags, per sé, are not "ricing". "Ricing" is more like an "state of mind". A flag becomes dangerous or counterproductive when uninformed people use it to "optimize" their systems. Then is when "ricing" is born. Most flags have a sense, and can be used productively on certain circumstances, it is the ricer who gives the ricing value to a CFLAG, and not the CFLAG itself.