RE: RFC: Optimizing for 386

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2005-01-21 at 00:14 -0600, Joseph D. Wagner wrote:
> > If you think there will be a performance gain, then rebuild /one/
> > RPM with the optimizations you want and show how much faster it is.
> 
> I actually did that once.  I recompiled KDE from scratch.  36 hours.
> No noticeable difference.  Then I recompiled the underlying Qt
> libraries from scratch.  5 hours.  A few seconds here, a few seconds
> there.  Then I recompiled XFree86 from scratch.  4 hours.  Now we're
> starting to talk increased responsiveness.
> 
> Then XFree86 became Xorg, and both Qt and KDE came out with a new
> version of there programs, and everything had to be recompiled from
> scratch all over again.
> 
> The problem is EVERYTHING from the ground up has to be optimized to
> feel the cumulative effect.  There is no way you are going to convince
> me that being optimized for a 386 is OK when I felt the effectiveness
> of optimizing the graphics programs.
> 
> However, because I didn't do my tests in a "scientific" manor with
> precise measurements, the developers won't even consider my results.

  I'd like to suggest for you to rally support from a few people to go
through the recompilations necessary for the entire distribution
(suggest using FC3 as the base) to prove the points you've been making.
There are a few things I think you will need to consider if you want to
be convincing.
  First, provide the entire resulting RPMS for download (bittorrent to
share bandwidth) for others to help out with benchmarking.  For the
truly paranoid (and to comply with most FOSS licenses), provide the
SRPMS as well.
  Next, be sure that anyone who does the 'subjective' part of the test
has two *identical* machines side by side to test simultaneously.  If
anyone's going to trust someone saying "It's faster" without hard
numbers, it'll be a hard sell unless there are no time and space
separators involved in the test.
  I'd also suggest making *both* machines dual boot with both the
original distro and the recompiled distro.  Boot one machine to the
original and one to the recompiled distro.  Time the boots.  Login and
time the login times.  Launch OpenOffice.org.  Launch Mozilla.  Launch
evolution.  Maybe do an 'rpmbuild --rebuild --target=i686 <kernel.srpm>'
on both at the same time and check out responsiveness during the build.
But do the same things at roughly the same time on each machine.  Time
how long it takes to launch each app under various conditions.
  Now repeat all testing, switching which version (original vs.
recompiled) is used on each machine.  This will help confirm that there
are no unknown difference that have any significant impact on
performance.  (It happens, even with supposedly identical hardware ...
anybody remember Gateway's graphics card of the month?  Even identical
model number cards can have different chipsets.)
  You may want to try the same tests with KDE as your default desktop or
XFCE as well.
  Be aware that even sometimes small variations in what you do between
the two boxes can (potentially) have significant impact later in
testing, so keep what you do as identical as humanly possible.
  You don't need a lot of people for this, but you do need some
dedication to coming up with some numbers.  If the above steps are taken
and you can come back with some rough numbers with a *real* recompiled
*full* distribution (or at least as full as you'd like to advocate ...
don't bother with bash if you think it won't matter).  Or maybe consider
just picking some of the key ones you've mentioned to start with like
xorg-x11, qt, gtk2, kde, and gnome.
  This whole exercise can serve a dual purpose.  If you end up having
trouble garnering the support you need to do this kind of testing, then
just maybe there aren't as many people clamoring for this kind thing as
you claim.  Or at least not as many people who want it who are willing
to prove their point.  Consider that if anyone wants to make a claim
that retargeting the distro for i586 or i686 or i686 with cmov or
whatever will improve performance, and if he wants anyone to believe
that he has the expertise to make that claim, then he should have the
expertise (and the willingness!) to prove it by take the steps I've
outlined above, or something vaguely similar.
  If you *do* get lots of people to participate, then the task will be
completed much more quickly and you will have some hard evidence to
report to those putting the distribution together for them to consider.
  Note what I'm suggesting here is not full-on scientific benchmarking.
But some initial hard numbers are necessary to convince the people who
will have to expend the most effort to implement what you are
suggesting.  More thorough testing can be done by more people if your
results show promise.
  One other thing you need to keep in mind as well: a modest improvement
may not be considered reason enough to make the change.  Particularly if
it leaves certain hardware in the dust.  And I'm not talking about 386s,
but some 686s (VIA?) that won't run the resulting binaries.  At least
that's what I'm hearing from people who know, like Alan Cox, if I've
understood correctly.
-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux