Perhaps Mandrake can/would compile the whole thing (distro) -mcpu i686 -02
instead of -march ???. That way you can ..."have your cake and eat it too."
Also, for those that just have to have more than what that offers (which is
little as it turns out , according to the gcc folks), then have the build
process passed a variable for compilation from a "rc" file in etc, which
itself can be changed easily enough. Many distros are doing this now.
Bob Finch
On Wednesday 19 March 2003 10:33 am, Leon Brooks wrote:
> On Wednesday 19 March 2003 04:16 pm, Gwenole Beauchesne wrote:
> > On Tue, 18 Mar 2003, Narfi Stefansson wrote:
> >> I believe that Steffen is right that mjpegtools was compiled without
> >> MMX in the 9.0 rpms.
> >> When I compile for i586 and athlon side by side and I enable MMX for
> >> both, I only get a maximum of 10-15% speed difference.
> >> The difference in with/without MMX is of course huge :-)
> >
> > No package will be built with MMX optimizations by default as there are
> > Pentium out there without those extensions. However, if your application
> > dynamically links against some optimized DSOs that would be fine to put
> > those libraries in */lib/mmx/* or */lib/sse{,2}/*. But you will be stuck
> > if they decided to dlopen() their plugins/libraries.
>
> OK, how about a half-step towards Gentoo?
>
> If URPMI knows what architecture it's really running under, you could add a
> new --optimi[sz]e switch to it so that...
>
> urpmi --optimise mjpegtools
>
> ...would download (if needed) or fetch from source CDs the appropriate
> SRPM(s), install them, rebuild them for the correct CPU, and (if needed)
> install the optimised RPMs over the top of the existing unoptimised
> package(s).
>
> It would also be relatively straightforward to cache/log the names of
> packages that had been optimised, to allow updates on same to be
> automagically re-optimised.
>
> What would be truly magnificant would be a way to do this and cache the
> results, so that the recompile need only be done once if the package is
> destined for a flock of identical machines.
>
> Next project, of course, would be `urpmi --optimize-all' followed by a
> 2-day pause while everything gets torn down, rebuilt and reinstalled. (-:
>
> Cheers; Leon
