Compiling for Speed? - where does Ubuntu keep the options?
UbuntuThis forum is for the discussion of Ubuntu Linux.
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.
Compiling for Speed? - where does Ubuntu keep the options?
Its about CFLAGS and -O2, and options like -march=<your architecture>.
There are things I am just not sure about.
eg - this PC has a Intel i7, which has a wealth of powerful instructions developed since 'i386', that the gcc complier might be able to compile for - if we tell it!
Where are the default options kept?
Even supposing one decides not to mess with Ubuntu defaults, how does one locally compile a program, optimized for the CPU, overriding the defaults?
How does one even tell if the 64-bit version got installed? In my case, it was provided by others.
My apologies if this seems a bit basic, but clicking System -> About Ubuntu can be surprisingly opaque on this little detail, even though you get the chance to choose at the site.
Ubuntu is a binary distribution, and in fact goes out of it's way to avoid the end user ever having to compile anything themselves. Not to say that you can't recompile things in Ubuntu with processor-specific optimizations, but that it really wouldn't work out as well as it could or should.
If you are serious about optimizing for your local hardware, you would be better off using a distribution that is ideally source based (like Gentoo), or at the very least is leaner to start with and gives you more control over building your own packages (like Slackware, Arch, etc).
You should also recompile your kernel with leaner options and targeted to your unique hardware configuration. This alone would net you a better performance boost than you are likely to get recompiling all your individual packages.
You should also recompile your kernel with leaner options and targeted to your unique hardware configuration. This alone would net you a better performance boost than you are likely to get recompiling all your individual packages.
My thanks MS3FGX.
I have once had a (not very competent, it must be said), adventure with Gentoo, which I do not regret at all, even though I eventually got seduced into the joys of Ubuntu. Gentoo has /etc/make.conf where compile control is kept.
I was thinking to choose (force??) the compile options at least for those programs I was compiling myself. From what you say, it seems a more flexible distro is a better option.
This is only partly about needing the performance (which I do). It is also about not simply ignoring the utility of all the expensively developed architectures, powerful pipelined instructions and suchlike so we can have a kernel that will even run on a 486.
Check Linux for a comparison between a highly optimized Gentoo kernel and Ubuntu, lets say that the Gentoo didn't exactly run away with the benchmarks, few tests it did well but not spectacular compared to Ubuntu, on other tests it was dead even.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.