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 â
