Pentium 4
Russell Coker
russell at coker.com.au
Tue Feb 3 03:14:05 UTC 2004
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
More information about the fedora-devel-list
mailing list