[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: autobuilder environment variables?

On Fri, Mar 02, 2001 at 11:21:34AM -0500, Camm Maguire wrote:
> Jules Bean <jules@jellybean.co.uk> 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
bound apps.

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
them, right?

Maybe this is all too naive, though.


Reply to: