Re: [linux-audio-dev] plugin loaders

From: Mario Lang <mlang@email-addr-hidden>
Date: Sat Dec 23 2006 - 15:25:14 EET

Fernando Lopez-Lezcano <nando@email-addr-hidden> writes:

> On Wed, 2006-12-20 at 15:43 -0800, Anthony Green wrote:
>> 2. We build binaries for the lowest common denominator, so the plugins
>> you'll find in Fedora, for instance, don't take advantage of SSE
>> hardware or instruction scheduling for different processors. This can
>> make a huge difference. What would be nice is if we could distribute an
>> RPM containing a plurality of plugin builds, and then have the
>> application load the plugin matching the capabilities the execution
>> platform.
>
> Perhaps it would be possible to create packages for "i686" in addition
> of packages compiled for the "i386" architecture? I think I used to do
> that for my Planet CCRMA packages... but I don't think I ever saw a
> noticeable difference in performance.

I still think the only true way to solve these issues is proper
runtime CPU detection, and optimized routines for specific CPUs.

This way, you do not extensively duplicate data. And you keep the
installation process simple for your users, and you can distribute
your packages in a standard way, without needing to care
about the i686 or whatever details.

JACK already does such a thing for its SSE mixing code...
mplayer also does something similar.

Simply maintain some function pointers for your algorithms that you setup
at init time after you figured out what the best implementations are.
You could even give them a spin by comparing performance at runtime,
and deciding on the results (the linux kernel does that for crypto
and raid algorithms).

You can even have gcc help you optimize for specific targets, simply
put target-specific code in a separate C file, compile it with your
optimisation options, and make sure in your program, the code only
gets called if this target has been detected.

This is especially cool if you think about a user changing ther hardware
components, but leaving their dsk driver untouched. Imagine you pull
your disk out of a certain machine, put it into another (with another CPU
type), and boot up. With runtime CPU detection, you get best possible
performance immediately, no need to reinstall any packages.

-- 
CYa,
  Mario | Debian Developer <URL:http://debian.org/>
  .''`. | Get my public key via finger mlang@email-addr-hidden
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-      <URL:http://delysid.org/>  <URL:http://www.staff.tugraz.at/mlang/>
Received on Sat Dec 23 16:15:03 2006

This archive was generated by hypermail 2.1.8 : Sat Dec 23 2006 - 16:15:03 EET