I am interested in making special builds of some of my debian packages in order
to tune them for the CPU of the specific machines they will be installed on. I
would appreciate any input you have on the best way to pursue this, as well as
which packages I should tune to get the most benefit.
I believe debian x86 is compiled for 386, and debian powerpc is compiled to run
on any powerpc. On x86, I think it would be worthwhile to make Pentium II and
Pentium III versions of some packages, tuned for the PC's I own, as well as
PowerPC G4 versions for my Mac. I may be getting a 100 MHz Pentium system for
free soon, and I think it would be particularly worthwhile to tune the software
on that machine.
I already have custom kernel compiles. I think this helps a fair amount.
I understand Mandrake is optimized for Pentium, and I've seen posts from
Mandrake users that say that this makes a great deal of difference.
I heard gcc version 3 has better processor-specific optimization, but it has
had a lot of bugs. But I understand that the 3.1 release may be of production
quality, though I have not tried it myself. I would be interested to know what
people think.
Unfortunately the packages that I think would yield the most benefit from
special compiles can be scary to build and replace.
I think that a processor-specific glibc would give a good performance benefit
to all my programs, but doing the wrong thing when upgrading it makes one's
machine just stop working, and then one also can't reboot. It would be
necessary to fix it while booted off an emergency disk, which I've actually had
to do when I tried to update my Slackware laptop when trying to install
packages from slackware-current on a machine that had an incompatible glibc.
However I have seen glibc upgraded several times while doing updates. Can I do
a manual update of glibc on a running machine using the debian package tools
without any problems?
An issue with building any libraries is that I would probably not want to have
processor-tuned builds for the static versions, to keep me from sending other
people programs that won't execute on their machines (or that execute very
poorly). One doesn't normally use much static linking anymore but static
versions of most libraries are usually available in case you want them.
Also, how would I be able to prevent the automatic upgrades of the packages I
have tuned? Maybe I can use apt's pin preferences for this. What I would need
to track instead would be upgrades to the sources, and then I would need to
rebuild.
The other packages I would consider tuning would be the XFree86 server and the
X libraries, the Gnome libraries, and Mozilla and the libraries it depends on,
the netatalk and samba fileservers, and maybe Evolution. I have built mozilla
and xfree86 before, and it's a fair amount of work. A mozilla build requires a
gigabyte of free disk space - when I built mozilla on my laptop I had to rush
around madly deleting unneeded files to keep the build going.
I think it would be really cool if Debian made processor-optimized builds of at
least the libraries available. I know that this would increase the developer's
workload. Maybe there would be some way that apt could be modified to enable
processor-specific versions to be installed automatically if they are available.
This would be a good opportunity for a commercial debian distributor, to offer
debian CD's where everything is processor optimized. Vendors who offered tuned
software like this might make better sales, especially if they continued to
maintain their distributions as debian is upgraded.
It would be worthwhile for some libraries to include processor-specific
optimizations in the source code, guarded by #ifdefs. You can do some of these
in C without resorting to assembly code, or you can use small libraries written
in assembly to give you access to the instructions you need. For example, I
have seen that the library source code that comes with the Metrowerks
CodeWarrior IDE has a lot of source that is specific to the PowerPC G4.
To some extent it can even be worthwhile to build optimizations for several
platforms and choose which one to use at runtime, by checking which
microprocessor a library is executing on. One trick is for a shared library to
consist mostly of stubs that call through to the real library, and then it
dynamically loads the best library for the processor at program startup.
Mike
--
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
[EMAIL PROTECTED]
Subscribe to the GoingWare Newsletter at http://www.goingware.com/newsletter/
Tilting at Windmills for a Better Tomorrow.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
