RFC: Optimizing for 386

[Sean Middleditch]

On Wed, 2005-01-19 at 23:16 +0100, Kyrre Ness Sjobak wrote:
> ons, 19.01.2005 kl. 17.08 skrev Joseph D. Wagner:
> > I can count the total number of people in the world who still use a 386 on the fingers of both of my hands.  Why are we still catering to this small group of people?
> > 
> > With the exception of the kernel and glibc, all RPM's are optimized for 386 architecture.  This is a waste of system resources.  Study after study shows that you can achieve a 10% - 40% performance improvement my optimizing code for a specific architecture.  Windows XP may only be optimized for a Pentium, but by golly, at least the whole thing is optimized, not just the kernel and the C library.
> > 
> > Just look at X.  Is anyone seriously trying to get X to run on a 386?  I can understand compiling the text-based programs, like bash, for 386.  You can run a text-only box on a 386 just fine.  Why do that for X?  Why do that for GNOME, KDE, or any graphical program for that matter?
> > 
> > I know that I can recompile of these program from the source code to achieve those optimizations.  However, why should everyone who wants to optimize their systems have to go through that, just so a handful of people with 386 machines can run X out-of-the-box?  Then, we have recompile all over again with the next RPM release.
> > 
> > Why can't the few people who have a 386 be made to recompile X from sources to get it to run on there machines, so the rest of us can enjoy the performance boost from running optimized binaries?
> > 
> > I think we seriously need to rethink the distribution strategy.  At the very least, all graphical programs should be optimized for i686.
> > 
> > Joseph D. Wagner
> > 
> 
> Actually, i don't think the CPU is the biggest slowdown for fedora. From
> my personal experience - memory (RAM) is a bigger issue. I have a 200
> mhz pentium 2 running fedora 3, full GUI and everything, and while i
> ain't claiming that it is hyperfast, its certainly usable. It has 384 MB
> of RAM.

Disk access is also pretty important.  I've started some "simple" apps
using strace and watched as screen after screen after screen after
screen of open/stat/etc calls were made.  GUI apps with all their icons
and external resource files and image plugins and so on are the worst.
The GTK+ folks are working on solutions in some cases (like icon
loading), but there's a lot that could be done by just slimming down
what apps need and how they go about getting those needs.  (Take a JAR
file - load the whole thing in RAM and get your code and data with only
loading one file off the disk.  I wonder how well that could work for
normal executables?)

> When it comes to startup times - how difficult would it be to (given
> enough RAM - autodetection+manual config) preload OpenOffice and Firefox
> on OS start, so it would just "be there" (like both of them are when
> first started) when the user clicks the nice, little icon?

I don't really believe much in preloading.  If you're a company CEO that
doesn't do anything other than make presentations and fire off a memo
here and there, maybe preloading works.  In general, though, spending
startup time preloading OOo just to have Mozilla kick it back out again
if you start Mozilla first, just isn't going to help - the preloading
only helps once and only if its the first large app you run.

Better to just slim down memory usage.  Or go buy more RAM, it's cheap.
Seriously, I've got a 512MB chip as a keychain ornament.  ~_^

> 
> Something that could be done to ease up OO memory usage, is make it stop
> loading a ton of dictionaryes. Well, it has certain upsides. Now i know
> that many mispelled norwegian words are correct in Hungarian...
> I have heard this is a goal for FC4 (splitting up OOi18n) - am i
> correct?
> 
> Kyrre
>