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

Re: RFC: Fedora Extras shipping ix86 optimized rpms?

Ralf Corsepius wrote:

>>But there .i686.rpm doesn't help you,
> Can you explain?
> It's the same approach RH applies to glibc and many 3rd party packagers
> apply to their package.

It is proved that a .i686 package for glibc has benefits.  If you find
some other package where this makes a real measurable difference, I
doubt that you'll find resistance.  But you have to prove it first.

> My actual concern is less the technical side, but the "policy side" of
> shipping "optimized packages" and its impact on "packaging"/"upgrading".

.i686 are not "optimized packages" if you cannot prove they are real
improvements.  Until then they are just doubling the QA efforts without
any benefits.

> Packing-wise, this has several disadvantages.
> 1. You'd have to compile library packages twice.

And for a separate .i686 this isn't the case?

> 2. Many packages contain both libraries and applications, so you'd have
> to apply special measures to assure that applications still get
> -march=i386 compiled. 

Most of the time this is no problem.  The application side is small, the
majority of the code is in the DSOs.

> 3. It would almost double the size of i386.rpms (These sse2 libs would
> have to be part of i386.rpms) - Is it worth it?

The size of the actual DSOs is not the only factor in the RPM size.
This means that two RPMs are bigger then one RPM with two DSO versions.

> However, I agree, it's a nice work-around suitable for libraries where
> special optimizations can be proven to have a "significant/noticeable"
> impact.

This is no work-around, this is the preferred solution.

And once again: provide us some data about packages where special DSOs
or even i686 versions are of benefit.  Make this analysis based on
modern hardware.  For instance, the Northwood cores and earlier benefit
more from special i686 rules than prescott and nocona.  And the latter
are the main targets very soon so adding something just for the benefit
of "legacy hardware" is not very attractive.

You can believe me, we are looking for possible ways to improve the
quality of the shipped code.  But the processor makers really do a good
job in having the processors execute plain i386 code as good as possible
on the processors.  Code generation changes have little effects.  Except
when it comes to using SSE2 etc, and there we already ship code using
it.  Look at the gmp RPM.

â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â

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