On Wed, 2004-09-01 at 18:17, Ulrich Drepper wrote:
Ralf Corsepius wrote:
>>But there .i686.rpm doesn't help you,
> Can you explain?
> My actual concern is less the technical side, but the
"policy side" of
> shipping "optimized packages" and its impact on
.i686 are not "optimized packages" if you cannot prove they are real
improvements. Until then they are just doubling the QA efforts without
Exactly, that's my point and intention (cf. below).
> 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?
There is a subtile difference:
* twice within the same rpm.spec
* building a package twice.
The former is more complicated and error-prone than the latter, e.g. in
the latter case you can pickup RPM_OPT_FLAGS and apply rpm's standard
%_*dir macros, in the former case you'd have to setup most *FLAGS and
> 2. Many packages contain both libraries and applications, so
> 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.
This isn't necessarily true for normal
For normal packages, you'd have to configure/make/install the package
twice, using different --libdirs and CFLAGS, etc. etc. and to sort out
those files which have been built and installed twice.
> 3. It would almost double the size of i386.rpms (These sse2 libs
> 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.
nevertheless it doubles the size of the rpms and doubles the size
of required disk-space. Instead of having to install one DSO, you'd have
to install two.
It's the classical multilib dilemma known from embedded toolchains:
Packaging simplicity and flexibility vs. space and bandwidth.
> However, I agree, it's a nice work-around suitable for
> special optimizations can be proven to have a "significant/noticeable"
This is no work-around, this is the preferred solution.
Uhh? I considered
Jacub's remark to be a proposal and recommendation,
and not to be a dictate.
And once again: provide us some data about packages where special
or even i686 versions are of benefit.
Sorry, you are barking up the wrong tree - I fully agree with you that
shipping and building "optimized packages" in most cases probably does
not result into performance gains.
The cause for me starting this thread is people already doing so in FE
and me questioning their procedures.
I did ask and received this in return:
The developers for scribus and inkscape believe that 686 optimization is a plus
for their apps (requested 686 packages for their sites), due largely to mmx. The
inkscape package disables mmx if built for 386, enables for 686.
One of the Scribus devels has did quite a bit of optimization during the 1.1.x
series, specifically some of these are helped by i686. This resulted in 50%
speed ups in user visible functions like screen redraws. e.g 5 seconds, instead
of 10 seconds to view a complex page.
Does this qualify as "proof of gain in performance"?
I really don't know.
I.e. I am asking for FE's packaging policy to be changed to not shipping
"optimized packages" unless compelling facts about the influence of
"optimization" on a particular package can be provided and reproduced.