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