Robert Jonsson wrote: I'm curious too about the performance boost we can achieve by recompiling HD Recording and software sampler/synths as 64bit. Any estimates ? (eg the same app delivers 50% more performance when run in 64bit mode) I mean: the Athlon 64 should provide higher memory bandwidth which is beneficial anyway but I'm curious if synthesis/processing is sped up too (by larger caches, 64bit cache bus etc). Or on the other hand if one could use 64bit integer processing substituting it to floating point processing. Juan L. always tells me about the great speed you can achieve writing audio apps that work with integers but I always felt that 32bit offers too little headroom (imagine mixing hundreds of voices with individual volumes without loosing the original sample quality and providing some headroom for FX processing etc. With 64bit this would be probably viable because it provides you a dynamic range of 385db without scaling and clipping. Or is the FPU in the AMD64 just as fast as the integer unit ? floating point is easier to deal with (because you do not need to fear clipping thus do not need to scale value to emulate fixed point fractional arithmetic), but we all know speed is one of the main issues in audio software. comments ? Benno http://www.linuxsampler.org

I know the Intel C++ compiler isn't free software (you can get it free as in beer to compile open source apps, though), but it's avail for Itanium.. I don't know how well it works with AMD's stuff. It's my compiler of choice. --- Robert Jonsson <robert.jonsson(a)dataductus.se> __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

There is barely any difference between integers and floats for math nowadays, if there is any, except that some operations can be optimized using bit operations and/or fixed point, like modulus, division, flooring, etc. The prime example on when your DSP algorithm becomes turtle is when you need to convert from float to integer, so you can get a value from a buffer. That alone can take a lot more time than the rest of your dsp code. floor() fmod() are also examples of complete slowdown (and then are many times necesary, for example, in something like resampling). But again, regarding to float->int conversion, As far as i know it is specifically a poblem with x86 processors? I know there is one instruction that does this, but it still takes several cycles. The reason why I use fixed point in my resamplers is basically this: I did many tests (which I can put online for you guys to check) on float vs. fixed point. The float versions were almost ten times slower, the reason for this was in around 70% the conversion of the sample pos to integer, for reading from the sample, and 30% in extracting the decimal part from it to perform the interpolation. Regarding to 64 bits, I'd like to add that there is a common misconception here. All the relevant buses can already transfer 64 bits in nowadays computers. The FPU and the extensions such as MMX or SSE2 already work in 64 bits. So there is not really any important gain in speed. The real gain from this new 64 bits architecture seems to me to be just more registers and larger adressing... Juan Linietsky