Re: [iiwusynth-devel] Re: Fluiwusynth

[Tim Goetze]

Josh Green wrote:

>On Wed, 2002-10-23 at 03:58, Peter Hanappe wrote:
>> 
>> Ahum... Ladies and Gentlemen, ... I unveil the new name of the synth:
>> 
>>      FluidSynth
>> 
>> And the new web site will be http://www.fluid-synth.org
>> (in some not too distant future).

makes for a nice opportunity to thank you for starting the
project, whatever its name.

>> I agree that we could in theory rewrite the voice loop in assembler.
>> As I mentioned in a personal mail, I rewrote the synth using fixed point
>> arithmetic but it didn't yield the hoped for speed improvements, yet. 
>> Because of that, I'm not sure whether the best thing to do right now is
>> rewriting in assembler. As long as we don't have a precise idea of
>> what's eating the CPU and as long as the synth isn't running fluidly I
>> think it might be a waste of time. Also, we'll have to do the assembly
>> code for Linux/i686, Win32/i686, and MacOS/PPC (and LinuxPPC? and 64
>> bits architectures?).

fixed-point is rarely a substantial increase in performance 
these days wrt float, and imo not worth it if you do not 
target integer-only DSPs. 

assembler is too tedious to write for generic functions, 
but some loops might profit from being hand-crafted.

usually looking at the assembler output from the compiler 
and deducing possible improvements to the C code is less
painful and almost as effective. different compilers act
differently of course, so this is less useful in a multi-
platform project like fluid.

although it can be a fun thing to write, maintaining separate
assembler fragments supposed to do the same on different 
platforms is a major nightmare, you don't really want it. 
 
>Actually its probably more than that (SSE/3D Now/MMX?). Of course all
>these are optional, and as long as they are fairly pluggable in the code
>(at least at compile time) they can be written whenever someone has the
>urge to (when they want better performance on their architecture). So we
>don't HAVE to write all of them, of course you know this :)

in fact, the only argument i see for using assembler is that
you can do SSE/3Dnow/AltiVec/MMX etc. gcc for example will not
use them, but they're working on it. the intel compilers will,
afaik.

>Any ideas whats the best way to code the assembler? I've never done
>inline assembler (I've only used NASM). In the current form it wouldn't
>seem possible to code the DSP routine in a separate object file since it
>is a macro and uses lots of variables in the C code. I agree that we
>should spend a good amount of time figuring out what actually needs
>optimizing before jumping in with assembler.

i prefer inlined assembler, conditionally compiled instead of
a C implementation. it makes it easier to compare what the 
code is supposed to do if the C code is just a few lines away.

>It would be very disappointing to go through all that trouble to get
>little gain. I think assembler by itself may give us some increase but
>probably not enough to be worth it (these days its probably hard to
>optimize code as well as a compiler can). I think we should look into
>taking advantage of single instruction multiple data technologies
>though, since most ix86 compatible processors have this these days and
>that will most likely multiply our performance.

yep, SIMD is the best option we have. the useful instructions
for our purposes however are either SSE or 3Dnow, which means
you can only hope to satisfy a fraction of fluid users (assuming
you're not going for PowerPCs). applied correctly, you can hope
for more than doubling the sample throughput in some places.

but SIMD works best with sample buffers that are sized in
powers of two. this is awkward once you realize you want
sample-exact event timing.

>> Cherries,
>> Peter
>> 
>
>Pickles..
>       Josh

quitten, tim