Slashdot Mirror
Optimizations for Source-Based Distributions?
Kenny Mann asks: "I currently run a Linux distribution called Lunar Linux and it is a source based distribution branched from the original Sorcerer GNU Linux. I've done a bit of research on compiler optimizations and such and was wondering what kind of performance is there really to be had for setting these options? I know that the more options the greater chance of unexpected failures, so my next question is what about optimizing your kernel?" Optimization is tricky, and I think the answer to this question is more complex than "yes, optimize" or "no, don't optimize". Rather there might be classes of applications that are safe to optimize and classes of applications that are not. How do those performance hounds out there feel about optimizing the kernel, however?
When a project is given to the opensource community, the optimizations that work should be submitted as well. Possible instability due to such optimizations should be noted, and where expedient, should be fixed.
This is usually taken care of in the form of a makefile. If the author didn't intend any optimizations to be run against the code, they didn't put them in the makefile.
It would be great, however, if there were a project to find out what instabilities happen due to specific optimizations, and either fix GCC so it can more intelligently tell when to optimize and when not to, or get code developers to adopt safe coding practices which will allow the optimizations to be made without problem.
-Adam
I'm not an expert on anything, but a friend of mine teaches at a local university, and when we were at my birthday party he mentioned having compiled an old encryption proggy he made (codigo pro) both under the ancient Turbo C and the most recent version of GCC. I dont know what settings he used, but he said it was like 3 times faster for the same code running on the same platform. :)
Of course he made the software ages ago when he knew very little about programming compared to now, and the source was probably lacking every possible optimization that an expert coder would introduce, so YMMV.
I never mess with settings when compiling programs under Linux, since I'm pretty much a newbie and often have trouble installing things from source.
However, an expert friend of mine who has a very old PC always goes for an LFSish setup where he compiles everything and tweaks all the settings by hand. He claims it works miracles, and I believe him. I know from my old MS-DOS graphics programming experience that small source and compiler tweaks could be the difference between a professional-looking program and a crappy amateurish app full of flicker.
I could ramble endlessly about all the optimization success stories from my youth, starting with the classic "DEFINT A-Z" QBasic trick, then progressing through Turbo Pascal compiler tweaks and finally achieving C + ASM goodness, but I shall not bore you any further
Check out other distro's forums and mailinglists. Sorcerer, Gentoo, and many others of these squeeze-everything-out-of-the-compile distros have great resources for this type of question. The Gentoo forums (https://forums.gentoo.org/) have quite a bit of talk about this sort of thing, but are more geared toward the portage system. However, threads about -fomit-frame-pointer and -funroll-loops can be enlightening - do they really give a speed boost, or do they just take up more disk space? Search away :)
I have seen a thread about optimizing the kernel on the Gentoo forums (guess which distro I spend time with?), but these seem to be much more hassle than they're worth in the long run in terms of segfaults and crashes and the like.
There should also be some sort of massive Linux bugzilla, with maybe an automated reporting agent like Windows and Netscape have. Applications can be written to call that program when an error occurs, or whenever the user wants to file a report. The data wouldn't even have to be looked at by humans, just be collected to tell what the most common problems are or maybe for a developer to search through later. I suppose the massive bandwidth costs would prohibit a project of this sort, but I still think it would be useful.
"I assumed blithely that there were no elves out there in the darkness"
First answer your question on kernel - the kernel optimization by default is good enough, e.g. it uses -Os instead of -O3 because some program like kernel usually run faster with less memory trace. You might want to optimize individual modules, though.
:), you could try some crazy optimization. The hardest thing to decide is that which optimization flags in gcc work best for your system. Should you use all optimization flags? Will these flags break your system?
:)
For the rest of the packages(I know you didn't ask, but it doesn't stop me.
Inspired by rocklinux, I've tried to benchmark individual optimization flag, i.e. test each flag and discard those flags which don't give your system performance gain. Of course, the script used in link above is pretty old and you must modify for gcc3.2+. Thanks to lameass filter I won't post my script here.
That sound like wasting of time but the result is satisfying. The max. yield I could gain is as much as 19% in comparing to plain -O3 optimization. Here are the result:
vendor_id : GenuineIntel
model name : Mobile Pentium MMX
flags : fpu vme de pse tsc msr mce cx8 mmx
gcc version 3.2 (i586-pc-linux-gnu)
Result: '-O3 -march=pentium-mmx -fomit-frame-pointer -finline-functions-fcse-follow-jumps -funroll-loops -frerun-cse-after-loop - frerun-loop-opt -fno-cprop-registers -funroll-all-loops -maccumulate-outgoing-args -fschedule-insns'
Performance gain(compare to -O3 only) ~ 9.9%
vendor_id : GenuineIntel
model name : Pentium III (Coppermine)
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
gcc version 3.2 (i686-pc-linux-gnu)
Result: '-O3 -march=pentium3 -fomit-frame-pointer -finline-functions -funroll-loops'
Performance gain(compare to -O3 only) ~ 13.7%
vendor_id : AuthenticAMD
model name : AMD Athlon(TM) MP 2000+ (a dual CPU system)
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
vendor_id : AuthenticAMD
model name : AMD Athlon(TM) MP 2000+
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
gcc version 3.2 (i686-pc-linux-gnu)
Result: '-O3 -march=athlon-mp -fomit-frame-pointer -finline-functions -fforce-mem -s -funroll-loops -frerun-loop-opt -fdelete- null-pointer-checks -fprefetch-loop-arrays -ffast-math -maccumulate-outgoing-args -fschedule-insns'
Performance gain(compare to -O3 only) ~ 19.6%
19.6%!! If you asked me, it worths it to optimize your desktop; but to the server, you'd like to have it running stable than to have it running 19% faster, you can trust me on that.
PS. In the processing of testing, I found some flags are dangerous and better use with care: -fmove-all-movables, -frename-registers and -malign-double. I suspected that they broke my file-util, which corrupted my entire fs. Just be careful.
See Kyle Sallee's comparison of source and binary distros at http://sorcerer.wox.org/docs/distro/distro2.html - source distros aren't just about those extra seconds.
/etc/fstab. Do it yourself! It's the natural thing for a geek to do - take it apart and put it back together.
They're about true dependency resolution - if you can configure the make file, chances are you won't hit any snags when running the program, unlike certain other binary package format I know.
They're about being up-to-date - what good is that security patch that came out 20 minutes after the bugtraq article if it takes your distro a week to release a binary?
They're about program selection - someone has to compile it, and like before, if no one has compiled it for your arch and your distro to your liking, you've got to do it or sit there on your heels and wait. Grab the latest version, test it out, submit a bug report, and participate in open source!
They're about learning - if you've never installed a distro from source, it's an enlightening process that is instructive. Forget Mandrake's Control Center that will configure your X server; forget about Debian's ncurses menu that lets you select modules to add to a precompiled kernel; forget SuSE's YaST that auto-generates your
They're about knowing what your system is running - unneccesary open ports are security holes waiting to happen. Do you really need telnetd running? Fingerd? Apache? Webmin? No? Don't compile them! Saves you time, space, and makes you more secure. The less extra stuff on your computer, the better. The latest versions of Mandrake and SuSE come on DVDs!!!! I probably have a 800MB of downloaded source between a server and a desktop; nothing compared to a full 9GB DVD or 7-CD set. I don't download what I don't use.
Source distro's aren't for every purpose. No corporate desktop needs Slackware. But for the geeks among us, they are a dream come true.