kc77 wrote:Flatland_Spider wrote:just brew it! wrote:Seems to me this degree of customizability is more valuable on an embedded platform with limited RAM and/or mass storage. For modern desktops and servers the size of the OS on disk and the memory footprint of the kernel are largely irrelevant. Disk space and RAM have both gotten cheap enough that only people with OCD care.
OTOH, a rather high percentage of computer geeks *are* afflicted with OCD to varying degrees, so there you go I guess.
A glut of computing resources and how the optimizations only produce minimal performance gains have been arguments against compiling from source for a while.
It is a little OCD. I like knowing what switches my programs were compiled with, and it's nice to know I don't have stuff that I don't need to cause security holes. Less code is better.
GCC for a lot of the older archs is pretty damn good with just march=native but the newer archs can still show some pretty big gains, 25% or more is'nt uncommon. Here's a comparison done on my system.
The top two are march=native. The bottom was compiled with this.
- Code: Select all
-O2 -pipe -march=bdver1 -mno-movbe -mno-fma -mno-bmi -mno-tbm --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver1
Here's another comparison with Apache.
To say my machine appeared to be something else after making those adjustments during compile time would be an understatement.
Sure, some specific packages gain a big boost using specifically-tailored compiler options. However I really think that is overkill to custom-compile an entire distribution, even considering how too aggressive compiler setting can wreak havoc on some programs.
I used Gentoo for 3 years and I was very satisfied with the results, but now I am much more pleased to use a Fedora or Debian-derived distro and compiling the specific package that benefit from aggressive optimization