17 Apr
2008
17 Apr
'08
3:54 p.m.
Christian Schoenebeck wrote:
Am Mittwoch, 16. April 2008 22:41:36 schrieben Sie:
For audio apps, the only bits that need real optimization are the parts
that sit in the audio path. I.e. The DSP bits.
These are normally best done with hand crafted code. So, one just
includes all the different CPU types, e.g. MMX, SSE etc. in one source
code. Compile it all as one, and then use runtime detection to select
the correct routine to execute.
For example, this is how most of libffmpeg works.
James
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