Subject: Re: [linux-audio-user] virtual sampler
From: Juan Linietsky (coding_AT_reduz.com.ar)
Date: Thu Mar 21 2002 - 22:29:51 EET
On Thu, 21 Mar 2002 19:52:18 +0000
Nick D <nixx_AT_nixx.org.uk> wrote:
> On Thu, 21 Mar 2002 16:16:20 -0300
> Juan Linietsky <coding_AT_reduz.com.ar> wrote:
>
> > On Thu, 21 Mar 2002 18:12:38 +0000
> > Nick D <nixx_AT_nixx.org.uk> wrote:
> >
> > > I don't think that's necessarily the case.. getting these things to run >fast is far from easy given the amount of computation involved, and >having something which works is surely more important? plus, if there >_were_ a documented way of getting much better performance, surely >everyone would use it? i certainly would ;-)
> >
> > It's not hard, basically, the idea is using fixed point math,
> > so you can easily take advantage of integer math being much faster.
>
> yes, fixed point is quicker. but it makes everything more of a pain to program. suddenly you have to be _very_ careful about overflows on signals etc... :-/ unless someone can tell me it really isnt much of problem - if it isnt then it's something i'd like to do..
btw, does anyone know what the (shudder) VST soft-synths use? fixed or floating point?
I think that basically depends on the plugin itself.
Fixed point is extremely use to use, since addition/substraction work
the same as with normal ints. the real problem is multiplying/dividing, (when it cant be done using shr/shl) since instead of multiplying by decimal values, you have to multiply for some value and then divide.
Converting to fixed point doesnt mean that you have to rewrite your whole app, it is actually easier to write your app using floats and only run the mixers in fixed point math. technically, 32bits is more than enough
since you work using a certain offset to the sample point.
> > There's also many factors that will affect the performance of your app
> > such as avoiding the use of stack in critical zones, avoiding large
> > precomputed tables due to cache size/associability restriction,
> > using "register" in values that hold the arithmetical operations (yes it > does work! i think gcc moves the variable to eax instead of using ebp > offset), and ensure that your code is simple enough so gcc can do a good
>
> -ffast-math makes a huge difference too.
> ive been using most of the techniques youve mentioned (most of the time), but does anyone know of documentation of this stuff? especially for optimising the output of gcc..
>
the output of gcc is extremely optimized, but what is really awesome is pgcc, which is sad that not many distros/people use.
> > work optimizing it. MMX is also nice for speeding up because it can > manage 64bits and many useful complex arithmetial operations, I havent > checked 3Dnow, simd, etc but i'm sure that those can be even more > useful.
> >
>
> IIRC, MMX is only for fixed point math(?)
MMX is integer math only yeah, sorry, what i meant with complex is that it does more than the common simple instruction thing.
> the others are more useful, but having to learn these instructions _and_ the hassle of assembly coding makes it an expensive (in programmer time) way to do it. although i would love to try these out, but i cant see how i would have the time, unless it were my job (i wish! ;-)
>
yeah, same here :)
regards
Juan Linietsky
This archive was generated by hypermail 2b28 : Thu Mar 21 2002 - 22:15:59 EET