Rebuilding Fedora

[Andrew Farris]

On Sun, 2004-10-24 at 21:42 +0200, Kyrre Ness Sjobak wrote:
> søn, 24.10.2004 kl. 21.34 skrev Andrew Farris:
> > On Sun, 2004-10-24 at 18:40 +0200, Roland Kaeser wrote:
> > > Hello
> > > 
> > > There is a mistake. I would like to completly rebuild the whole 
> > > distribution rmps from the srpms iso's not just the kernel.
> > > 
> > > Kind regards
> > > 
> > > Roland Kaeser
> > 
> > Are you considering the amount of cpu time required to build this entire
> > distro?  It is not something I think you want to do on a workstation,
> > I'd suggest rebuilding only those individual packages for apps you run
> > constantly.  Build firefox, the KDE packages, xorg-x11, and the kernel,
> > perhaps a very few others.
> > 
> > If absolute optimization is your goal, go Gentoo, and experience that
> > extra 5% Alan is talking about in his post.  I've found rebuilding i686
> > for the constant use packages makes them 'feel' faster, but I am not
> > positive it is more than illusion.  Rebuilding FC2 will take longer than
> > a complete build of Gentoo.
> > 
> > Why will it help very little?  FC already used the best possible choice
> > of instruction order for pentium-pro and up machines, which means unless
> > your app is going to be using SSE instructions there isn't that much
> > more you can do.
> > 
> 
> Yes, but (being anything than a compiler specialist...) can't you
> optimize specialy for a spesific CPU, not just an arch? And how can this
> affect loading times?

I'm also not a compiler specialist, but here is a general overview of
the situation as I understand it.

Yes, there are three main compiler setting choices of interest you could
change.  What instruction set to use (march), what optimization level to
use (Ox), and what instruction ordering to use when optimizing (mtune). 

Fedora uses march for i386 machines so that the code will work on old
hardware, but optimizes O2 (the fastest considered stable and reliable)
and an mtune for i686 (pentium pro) so that it runs the best order of
instructions for a i686 it can.  From there on up the architectures
change most in ways that compiler optimizations do not capitalize on, or
that the hardware does despite your code (some cpus actually disobey).
You can optimize to a higher level (O3) but you see marginal gain and
instability, or you can use higher instruction sets which will see gain
but only for types of code that exploit the instructions (streaming
media mostly).

As for load times, you will not see excessive change in that, what
you'll see is lower cpu usage at peak load and lower latency when
performing more tasks at once (jerky responsiveness).

Lower load times are most effected by Prelinking, so making sure that
your system is not failing to complete the prelink is something you
could do quickly.

-- 
Andrew Farris (lordmorgul) <andrew at andrewfarris.com>
- CPE student, Cal Poly SLO, pgp keyid 4430F405 pgp.mit.edu
"..the triumph of evil is for good men to do nothing." (Edmond Burke)