iiwusynth-devel
[Top][All Lists]
Advanced

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

Re: [iiwusynth-devel] Re: Fluiwusynth


From: Josh Green
Subject: Re: [iiwusynth-devel] Re: Fluiwusynth
Date: 23 Oct 2002 09:29:41 -0700

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).
> 

Yeah! Lets make a toast.. To FluidSynth!

> 
> 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?).
> 

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 :)

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.

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.

> Cherries,
> Peter
> 

Pickles..
        Josh





reply via email to

[Prev in Thread] Current Thread [Next in Thread]