Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Heard from someone that it's possible to compile software from source and play with gcc flags to increase performance comparing with pre-comiled binaries... is it true?
as far as i know, re-compiling kernel with suitable options that match your needs and hardware would speed up the system and shrink down the size of the binaries and i can learn some of its techniques in books like O'Reilly understanding linux kernel... but how about other software such as firefox? I use mac mainly and people's been going firebox optimized for G4 and things like that and i'd like to learn but don't know where to start with..
contrary to popular belief size of the binaries and speed are often not in any way the same thing..
Linux and GNU programs in particular are optimized for speed not size..
But with the kernel like you said just eliminating stuff you don't use is a different story.
Todays processors have some very deep pipes that can handle things like urolled loops which are larger and faster. (don't know about motorola cpus) Also binaries can be sripped of debugging symbols for size but contrary to popular belief this has no effect on the amount of symbols loaded at runtime. This may effect scan time in some way however looking for symbols.
So anyway yes you can increase the perfomance of you machine greatly with compiler flags but do lots of benchmarking first to decide what flags to use and realize alot of what you read on the internet about this is just mythology.
When you compile the kernel you have to hack the Makefile to add the gcc flags and get verbose output so you can see the exact effect of what you are doing. The kernel takes well to agressive optimizations.
Some other programs if you use agressive optimizations end up broken and unstable
(both Firefox and X where broken by optimizations on my machine)
also never try to optimize the core like gcc itself or glibc.
have fun
Last edited by foo_bar_foo; 01-17-2005 at 12:37 PM.
see here (assuming your running an x86 or x86_64 architecture )
for details on what options you can pass. But be warned, as foo_bar_foo stated above, if you try to over do it you may end up with a program that behaves oddly/crashes regularly. to set the flags do:
Code:
export CFLAGS=" <options "
So for example if you wanted to optimize for your processor ( which we'll assume is an athlon-xp for this example):
Code:
export CFLAGS=" -mcpu=athlon-xp -march=athlon-xp"
the -mcpu options tells the compiler to optimize for the athlon-xp but allow older processors to still run the code. The -march option tells the compiler to fully optimize the code for the athlon-xp, but to the point where athlon-xp is the minimum processor which will run the code.
You will have to experiment with different options to see what you like best. My personal opinion is stick with light optimizations ( like -mcpu and such ) as the more you throw in, the less stable things tend to become. Also, the perfomance gain isn't exactly night and day either. You may get a touch more responsiveness ( this is debatable) but overall ( In my opinion ) its not worth recompiling your whole system over to try to get better performance.
ps - if your compiling c++ code, you'll have to set CXXFLAGS too like this (assuming you have set CFLAGS like above):
Originally posted by foo_bar_foo Some other programs if you use agressive optimizations end up broken and unstable
(both Firefox and X where broken by optimizations on my machine)
I may not be optimizing as aggressively as you, but my own Firefox build, optimized for Pentium 4 / SSE-2 using -O3 and a few other flags, runs well on my Linux box.
Originally posted by daihard I may not be optimizing as aggressively as you, but my own Firefox build, optimized for Pentium 4 / SSE-2 using -O3 and a few other flags, runs well on my Linux box.
this is interesting and an indicator of how complex it can all get
i had to take away even the default optimizations or i got the loop thing at startup even as root..
what you said implies it's because i optimized other underlying libs.
In my opinion, as long as you stick to modest optimizations, like the O flag and cpu optimizations, you'll be alright. But in my experience, trying to throw too many flags into it will break some code. And it also depends on the flags themselves, as optimizing for a pentium 4 gcc will do completely different things than if had optimized for an athlon-xp or something else.
This discussion leaves me wondering what optimization is all about. After all, all the source code is written in grammatically correct language (be it C or Java or whatever else) by definition; otherwise it would not even compile. Yet optimizing that grammatically correct code may break something - to me, that can only mean a bug (or bugs) in the compiler.
I remember the flag "-match=pentium4" did not work with GCC 3.2.x when I compiled Firefox with it. The binary was built, but it would not run. The exact same flag now works with GCC 3.3.x.
I don't think it's a bug, I mean when you optimize moderately, chances are you'll never have any problems.
But when you start throwing some of these in at random, you could break the build ( especially if the programmer used things which were not illegal, but not technically correct either like depending on sizes of structs, manipulating pointers in unintended ways, etc...). Note that some of those options above when given to gcc will tell gcc to break the ANSI standard if it has to..
Yeah, it's a common sarcastic expression but this time I actually mean it. The optimization flags passed to gcc do not really have anything to do with the code itself. They control the way gcc handles different operations - like unrolling loops to save a few cpu cycles but spend a few more cpu registers.
The flags differ between different versions of the gcc compiler, and CPU types are constantly added or altered: The AMD processor family formerly known as "k8" is now referred to as "athlon-4" in gcc 3.3.5, and so on.
I know what you guys are saying, but when it gets right down to business, my opinion is that the compiler should not attempt to optmize the code in a way that may break the resulting binary, no matter how badly the source is written.
I am a C programmer, so I know it's very easy to abuse the C language. However, most of the modern C compilers are able to give you warning about bad, if not illegal, code (such as using pointers interchangeably with non-pointer data types). I agree with you that code full of such warnings may result in non-working binaries if optimized aggressively, but clean code should always be built to run - whether or not optimized. In my opinion, anyway.
(But again, I know it's not too hard to fool the compiler to give you no warnings using explicit casts and other things...)
As for the "-march=pentium4" flag, it was present with GCC 3.2. It just did not work as intended, at least when I built Firefox.
Originally posted by kuranosuke
Although, to note: you probably will not see much of (if any) a NOTICEABLE speed increase.
i disagree with this
i use a very basic non-esoteric benchmark as an example
on my machine with -O flag
10 second file copy 63787KBps
with -march=pentium4 -O3 -funroll-loops -ftracer -momit-leaf-frame-pointer -fprefetch-loop-arrays
10 second file copy 71242KBps
that's what -- a little over 11.5% increase on a basic simple operation
Originally posted by daihard my opinion is that the compiler should not attempt to optmize the code in a way that may break the resulting binary, no matter how badly the source is written.
wow that would mean just one compiler that compiles things only one way..
(lost in 1982 forever no matter where the hardware goes)
then you just pretend like the code is good just cause you can get it to compile (aka Micr$ft)..
sometimes the compiler has bugs but more often then not it's the code with bugs and design problems that are being brought out by the optimizations and are hiddden otherwise..
so code should be tested on all kinds of equipment and with all kinds of optimizations and even be tested on different compilers to weed out the funky stuff.
you cold turn this around and say -- no matter how badly the compiler is written no code should be written so it breaks when optimized for certain architectures.
Originally posted by hw-tph Some applications really do benefit greatly from being built with options specific to your hardware - mplayer for example.
Håkan
Well, i dont know if it's true or not, but for me, although i compile mplayer 4 times with many options (-gui, -crash-debug, cpuruntime-detection, --enable-dvdread) it still crash whenever i play dvd from dvd+rw !!!!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.