Re: autobuilder environment variables?
On Fri, Mar 02, 2001 at 11:21:34AM -0500, Camm Maguire wrote:
> Jules Bean <email@example.com> writes:
> > On Thu, Mar 01, 2001 at 04:13:35PM -0500, Camm Maguire wrote:
> > > Greetings! Do the autobuilders set any particular environment
> > > variables? Is there any other way that 'apt-get -b source <package>'
> > > can build a package customized to the user's hardware, but the
> > > autobuilder build a generic binary that will run on all systems?
> > > (i.e. consider i386 extension instructions, such as 3dnow and sse).
> > >
> > > There seems to be some consensus that it would be better not to have
> > > the atlas package, for example, compile tuned libs under /usr/lib/sse
> > > and /usr/lib/3dnowext, but to rather compile a single lib, and have an
> > > easy procedure for the end-user to rebuild from source and tune the
> > > package to their hardware.
> > Hmm. The 3dnow and sse portions of code tend to be small; many
> > programs I've seen simply compile them all and select the right one at
> > run-time. Bloat, obviously, but not much bloat I don't think.
> > Or is that not appropriate for atlas?
> Well, this is rather contrary to the design of atlas. Atlas has been
> designed for speed above all else, and is intended to be tuned to an
> end-users particular hardware -- i.e. it is not intended to be
> portable. This makes distributing a binary package tricky -- should
> we stick purely to this philosophy, or cover a few of the major bases
> in a basically transparent fashion?
Well, I'm no expert, but my understanding has always been:
The new instructions in the core set, as we progressed
386-486-586-686, have not afforded much speed benefit even to CPU
The pipelining-type instruction order optimisations can often be
undertaken to a suitable degree without harming speed on any CPU
And that leaves the 'special' instruction sets: Screaming Sindy,
3DNow, etc. And it's not exactly expensive, either in code size or
runtime to have a runtime-conditional jump to the optimised chunks.
After all, you only bother to code a few really core code-paths in
Maybe this is all too naive, though.