[LAD] optimum binary distribution (was: vectorization)

[Christian Schoenebeck]

Am Mittwoch, 16. April 2008 22:41:36 schrieben Sie:
> You are not really following what I am trying to get across.  Cross
> compilation isn't the issue.  The issue is that something as generic as
> i386 (or i686 for rpm based distros IIRC) actually targets a lot of
> different types of hardware. It can run on pretty old pentium based CPUs,
> but also modern
> systems.  A binary distributor has no way of knowing which
> CPU is going to be used, in fact, a single binary package
> is going to be used by many of the supported variants.

Trust me, I can follow what you mean and I also thought about a solution for 
that problem years ago. The point is, where do you draw the line? You might 
say, for the x86 architecture you detect at runtime whether the system 
supports: MMX, SSE(1), SSE2, SSE3 and precompile 5 binaries which is going to 
be picked automatically at application startup. Unfortunately that's not 
sufficient to achieve max. performance. On some weak systems for example you 
achieve better results with -Os than with -O3. So wanna make extra binarie(s) 
and runtime benchmark for that as well? You could continue that game for a 
lot of other GCC flags and your binary collection would grow to a horrible 
huge cross product. And we're still just talking about one architecture.

That's why I was thinking about a little different approach for binary 
distributions: just precompile some part of the audio application (/most of 
it) and actually compile the core elements (the ones that are crucial to 
overall performance) on demand by the user. Because I agree compiling a whole 
complex audio app is usually an unconvenient user-unfriendly task, especially 
because all of those library dependencies and system specific path locations 
etc. the user has to deal with and the long time it takes to compile the 
whole beast. But with such a partly precompiled solution you (as a 
distribution package maintainer) can already take away those hairy tasks, 
because the few core elements that are going to be compiled by the user will 
only have fery few dependencies left: the applications own library (which is 
already there anyway) a compiler and very basic standard header files like 
math.h which are usually there on a machine with compiler anyway. And since 
those dependencies are so small, it wouldn't be a hard task to integrate such 
a build system into the application itself, so the user just has to adjust 
the CXXFLAGS in a line input box or something and press the "Recompile" 
button.

CU
Christian