Pentium 4

[Russell Coker]

On Tue, 3 Feb 2004 12:38, Gerhard Prade <gerhard.prade at uni-bielefeld.de> 
wrote:
> i am not a developer, but have a question. I tried last time
> Gentoo-Linux and i think it is great to optimize a hole distribution of
> linux for a CPU-Achitcture (like Pentium 4 and not only for 386).
> But Gentoo is for me not easy to use. So i want to use in future fedora,
> like i do now.
> Now my question. It is posible to optimize one of the next releases of
> fedora for 686 CPU or greater like Pentium 4?

The level of optimisation that Gentoo does is not desirable (IMHO).

It means that every possible compiler bug related to CPU optimisation will be 
tickled, and that not all combinations will receive good testing which means 
that the chances of trying a random program on a random CPU is more likely to 
give bad results.

When reporting a bug it may be that you have an uncommon CPU and the 
maintainer of the package may find it difficult to get access to the same 
CPU.  This makes it more difficult to reproduce bugs.

Distributing RPMs for all the different CPUs takes significant archive space 
and significant numbers of CDs.

There have been many discussions of various ways of optimising programs.  The 
conclusion of the last discussion I saw was that there is no set of 
optimisation options that will be best for every program on a given CPU.  The 
question of when to use -Os and when to use -O2 is not an easy one to answer!

Finally, in most cases of compiler optimisation the payoff is small.  Changing 
the algorithms used by programs can deliver much more significant results, 
here are a few examples:

KDE performs poorly when large amounts of text are in a window, EG when kmail 
displays a message with a few megs of text.  I've seen the same operations 
run faster on other GUI software on 386 machines than kmail runs on P3 
machines!

kview and konqueror cause the X server to take up large amounts (600M or more) 
of memory when displaying 10,000 x 10,000 PNG files.  Mozilla and xv display 
the same files without requiring any significant resource usage from the X 
server and the entire system runs a lot faster.

As of my last test OpenLDAP was CPU bound for most of the process of importing 
an LDIF file and used only a single thread.  So for a medium size directory 
40M of CPU time would take 45M of clock time on a 2 CPU hyper-threaded 
machine, while ideally the work could have been done in 25M of clock time or 
less.

GPG will in some situations take ages to update the trustdb.  When I 
regenerated some of it's caches to try and track down another bug the 
update-trustdb time went from 23M to 1.5M!  This should be fixed so that it 
will always run fast for everyone.


If you make such an optimisation to one of the programs that is important to 
you then the results will be better than anything you could achieve through 
compiler optimisations.

Maybe we should create a list of programs who's performance is an issue for 
Fedora so that interested people can start investigating them?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page