[KLUG Members] Re: REDHAT: My suggestion on organizing binary CDs for x86 chip-specific optimizations

[Bryan J. Smith]

On Tue, 2002-04-16 at 08:42, Bruce Smith wrote:
> Oh, okay, I'll comment.   :-)
> First on the NFS distro.  That's a very good idea, but personally I
> don't have enough Linux boxes to make it worth my while.  For KLUG it
> wouldn't sell any CD's.  When the day comes when we convert all of our
> Windows boxes to Linux at work, then I'll probably make a NFS distro
> available here.  (unless we go with all LSTP boxes :)

Right.  I was just saying the "NFS approach" is how I handle dealing
with updates, added packages, optimizations, etc...  I just lug my
notebook everywhere I go, and install it for people.  If they want a
copy, I plunk the ~2GB over on one of their servers or on the same
system (if they don't have another).

> As far as creating different CD's for different CPU's, that's something
> I've kicked around for awhile.  I think it'd be great to have an P-II+
> and an Athlon only distribution.  However . . . I'm not sure it's worth
> my time - personally.  And it WOULD take a LOT OF EXTRA TIME!

Right!  It is far more difficult to do it for CDs.  Since my NFS
approach solves the issue for me, there is no incentive to do so.  But
for RedHat, _yes_ it would be _ideal_ so all can benefit!

So I made a suggestion to RedHat on how to approach this in a way that
adds the fewest CDs possibly, but expands their options.  Furthermore,
it also addresses the forthcoming issues with x86-64 optimizations.  At
the same time, the "Default" CD #1 is what most users would still
download and distribute.  The additional CDs are just for servers, IT
professionals and/or enthusiasts as warranted.

> If there was a GREAT demand for it from CD buying KLUG members, then I'd
> think harder.  A LOT greater demand than I have for the SGI/XFS CD!!!

The new "approach" wouldn't change SGI's ability to add another CD to
the mix.

> With the price of hardware now, is it worth the time to create a CPU
> specific distribution?

Yes.  MMX, SSE and 3DNow! make a _crapload_of_difference_ when it comes
to multimedia, scientific and engineering -- we're talking upto an order
of magnitude!  AMD's extra FPU pipes often go unused as a result of not
having optimizations.  Heck, 3DNow! can accelerate some network
operations too.

Mandrake has found that Pentium optimizations result in a ~30% increase
in performance.  I'm talking taking this to a new level, one that's
going to be required for x86-64 anyway.  So instead of making one CD set
for x86 and one for x86-64, why not make a more "modular" CD set for
accommodating different x86 CPUs with only one CD change?

> Personally, I have more CPU horsepower than I need on my desktops.
> My favorite editor is VI, would a i686 optimized VI binary help me?
> I think not.

*SMACK*  ;-P  Did you or did you NOT read the _details_???  Something
like ViM would *NOT* be improved by CPU optimizations so it would *NOT*
go on CD #1.  If you _read_the_whole_post_ you will noticed that I
_explicitly_realized_this_ and thought I accommodated it quite well. 
;->

So, to "reash," I'm talking about a _limited_ number of packages being
CPU optimized -- only about 25-40% of the i386 binary packages
_at_the_most_.  Not a 100% x86-specific optimized distro on the whole. 
You'd have one CD "option" for i586/686 with mainly i586 optimized
binaries for both, and a few i686 optimized binaries where it made a
difference over i586.  Same deal with Athlon/x86-64, where you'd have K7
optimized binaries for both, and a few K8 optimized binaries where it
made a difference over K7.

> All my servers have underutilized CPU's now, so slightly more
> efficient binaries wouldn't do me any good.

*SMACK*  ;-P
1.  CPU Utilization != Server Throughput
2.  x86 chip-specific optimizations can affect I/O as much as CPU

It goes even deeper.  RedHat, SuSE and other distributors have started
including different binary kernels to address different memory
models/addressing, components, optimizations, etc...  As such, over
100MB on a typical distro is used to just store all these binary kernels
options.  It is only going to get worse as more and more are added.

As such, this model addresses the problem of "stuffing" more and more
pre-built binary kernels on a CD.  You just put the common, uniprocessor
kernels on the "Default" CD #1, but you can get more specific with MP,
Enterprise, etc... on the "Pentium/II/III/4" or "Athlon/x86-64" CDs,
respectively.

> But I'm only one case.  How about everyone else?  How many people would
> notice a 1%-10% performance boost in _certain_ binaries?  (the kernel
> and glibc are already CPU optimized, for the most part)

Try even 200-300% in some applications!  Or don't you understand the
concept of SIMD let alone general ALU and FPU optimizations and other
details?  I love how people talk about the Athlon is "as fast or not as
fast" as the Pentium CPUs based on _Intel_optimized_software_.  Have you
_ever_ run software that is Athlon optimized???  If the Quake 3 engine
was offered in an Athlon optimized version, it would run ~40% faster
(let alone probably slower on Pentium CPUs).  I'm not just talking
MMX/SSE v. 3DNow! here, but optimized binaries as a whole.

Trust me, it adds up quickly.  I've gotten a major boost in my
system-wide performance with an Athlon-optimized GLibC and a few other
libraries, especially SDL and other A/V/multimedia ones.

> And for you guys running Linux on an old 386, you already have a
> complete distribution optimized for your specific CPU!!!   ;-)

And that would *NOT* change for them in the new model.  The "Default" CD
#1 would address most everyone.  At the same time, those with newer
systems would have optimizations that would probably outperform
Mandrake's i586 "optimized-by-default" distro.

-- Bryan

-- 
The USDOJ v. Microsoft trial will result in unconditional surrender.
No matter who wins, the consumer will be subject to the victor's
"terms."  Which is worse?  Clueless government or clueless monopoly?
--------------------------------------------------------------------
Bryan J. Smith, SmithConcepts, Inc.        mailto:b.j.smith@ieee.org
Engineers and IT Professionals          http://www.SmithConcepts.com