Re: subarchitectures (was Re: What to do with optimization flags ? )
Greetings! This is a good question, and I'd like to solicit the
feedback of likely atlas users on this.
1) Would you prefer the package to
a) install the best binary for your system
b) install all binaries appropriate to you arch under the
appropriate /usr/lib/??? directory
c) query you for which binary to install
d) install a generic arch binary that covers all bases, and
provide a note that performance could be improved if the user
would rebuild the package on their system.
2) 3dNow! is not ieee compliant -- i.e. there is no inf, nan support,
etc. Which option a-d above would you prefer for this cpu?
Please also indicate how much 'value-add' you think there would be to
Debian to offer precompiled binaries optimized for subarchitectures.
The performance differencecs in the cases under consideration are
Rob Latham <firstname.lastname@example.org> writes:
> Ben Collins (email@example.com) said:
> > On Thu, Dec 07, 2000 at 12:14:53PM -0500, Camm Maguire wrote:
> > > 4) Most importantly, it appears that atlas cannot cross-compile,
> > > i.e. the compiled code must *run* on the compilation machine. From
> > > what I can see, this makes it impossible to autobuild fully
> > > optimized version(s) of this package given the current machines at
> > > Debian's disposal. I can set the package up to autobuild a generic
> > > x86 lib, like it does currently, which will autobuild successfully.
> > > But I could also produce a fully optimized binary package covering
> > > p3,p2,k6,k7 given the machines available here. My question: is
> > > there anyway to get such a binary package to override the
> > > auto-built binary packages in the distribution?
> > That's a downfall in atlas, IMO. There should be a way to compile for a
> > CPU, without actually having that CPU. You will most likely have to hack
> > the atlas build process to get this done.
> Is rebuiding from the source deb acceptable? If one is using
> precompiled binary packages, one has to accept that the packager is
> aiming for a wide target at the expense of speed enhancements. The
> users will gladly recompile if it's only a step or two, and that's all
> it takes to see speedup
> As long as the rebuilding step can be expressed as one command line,
> i'd say that's the best you can hit without infinitely diverse
> Rob Latham: linux A-Team Bethlehem, PA USA
> EAE8 DE90 85BB 526F 3181 1FCF 51C4 B6CB 08CC 0897
Camm Maguire firstname.lastname@example.org
"The earth is but one country, and mankind its citizens." -- Baha'u'llah