On Tue, Jun 29, 2004 at 10:19:32AM +0200, Benno Senoner wrote: I dont think this is right, fractional will be [-0.5, 0.5], rather than [0,1] which is more noirmal as lrintf() rounds to the nearest. I think you should be using lrintf(floor(x)) or (int)x.

- Steve

so if you want quick fractional sample lookups, the best option on x86 i see is to manually "fldcw" before and after your sample loop, and use lrintf() or "fistpl" directly to obtain integer indices inside the loop.

The problem is that the rounding mode affects all floating point operations, such as multiply and divide. And normally you must do rounding and not truncation. Thus changing the mode will change the results, and a compiler is not allowed to do that.

Only in very specific cases, such as a loop that converts an array float values to integers, where the truncation is the only floating point operation in the loop, is the compiler allowed to do the mode settings outside the loop. But I'm not sure if gcc does this.

[Jens M Andreasen] if we want to use the integer part as sample index for a memory lookup, having it in double/float doesn't buy us much: we still need to convert to int type, which is costly. regarding lrintf() on x86: checking the output of gcc-3.0 -S, you can see that it compiles to a simple "fistpl" instruction. this instruction relies on the current FPU control word, which defaults to 'round' not 'truncate' (which isn't what we want for memory indices). now, "i = lrintf (floor (f))" compiles to "frndint" surrounded by "fldcw" (load control word, which is __slow__), and finally "fistpl". in contrast, "i = (int) f" compiles to a single "fistpl", but of course (the gcc default FPU control word defaulting to 'round') also surrounded by "fldcw". so if you want quick fractional sample lookups, the best option on x86 i see is to manually "fldcw" before and after your sample loop, and use lrintf() or "fistpl" directly to obtain integer indices inside the loop. incidentally, you can find a portable implementation in the caps package. tim

Hi all, please note that SSE2 has support for 64bit floats (doubles) and contains an instruction that truncates to int, irregardless of controlwords. A new enough gcc with (-march=pentium4 or -msse2) and -mfpmath=sse will use sse instead of the old fp unit. This has more advantages, since sse math uses normal registers instead of the stack in the old fp unit.

[Ruben van Royen] afaik, the athlon XP here only has SSE (not ~2), but the instruction set includes this (quote taken from the NASM documentation, section B.4): CVTTSD2SI reg32,xmm/mem32 ; F3 0F 2C /r [KATMAI,SSE]

CVTTSS2SI converts a single-precision FP value in the source operand to a signed doubleword in the destination operand. If the result is inexact, it is truncated (rounded toward zero). The destination operand is a general purpose register. The source can be either an XMM register or a 32-bit memory location. If the source is a register, the input value is in the low doubleword. - the operand requirements are quite different from "fistpl" so replacing one with the other requires some additional instructions to move the data around.

tim

Jens M Andreasen wrote: The problem of modf is that it is slow (it generates "call modf" which involves subroutine calling, even with -ffast-math), and the integer index is still a double which needs to be converted to an int, so you need do perform either a fistl or lrintf(); I benchmarked my code agains the modf() code and mine is 3 times faster. As said in my code the fract part might become 1.0 in some cases or even if it got a bit below 0, for interpolation it still works perfectly because the continuity of polynomial interpolation. In LinuxSampler all we want is fast interpolation and the current code we use is efficient. We will explore the possibility of using fixed point (int/fract part, eg 16/16 bit) indexes perhaps we will squeeze out a bit more but on the other hand it has the problem that if you need LFOs and other kind of pitch modulation you have to convert indexes from float/dobule to fixed point which might be a bit timeconsuming, especially because we have sample accurate modulation and envelopes. We will see what can be done, for now the goal is to get a perfectly working sampler engine. 5-10% of performance increase is not that important for now, especially if fixed point indexes turn out to be a big PITA. (cannot say yet, whether this is true or not, one has to implement and benchmark the stuff within the whole sampler engine to get real numbers, synthetic benchmarks are not alway enough because in a complex audio app you do lots of other stuff besides resampling) regarding SSE/SSE2: I performed various benchmarks (pure C/C++) with gcc 3.3/3.4 and the latest intel compiler with SSE vectorization optimizations: the fact is as Eric said that SSE/SSE2 is slower than the regular FPU in some cases. Resampling (polynomial, eg linear, cubic) seems such a case. Not much can be parallelized (icc is not able to vectorize anything in the code below) so you either use an alternative algorithm handcrafted for SSE or you better stay with the regular FPU. I'm not sure if it is possible to achieve decent speed increases with SSE, perhaps it would help to keep track of 4 indexes eg. double fullindex1, fullindex2, fullindex3, fullindex4; double fract1, fract2, fract3, fract4; int intindex1, intindex2, intindex3, intindex4; double pitch; ( eg 1.0 plays the audio at normal speed) for(...) { // fullindex1 is the official index (incremented by pitch at each interation) , fullindex2,3,4 are the indexes needed // can the following 3 lines be parallelized ? fullindex2 = fullindex1 + pitch; fullindex3 += fullindex1 + 2.0 * pitch; fullindex4 += fullindex1 + 3.0 * pitch; // AFAIK SSE2 can do 2 double_to_int with one instruction // see CVTPD2PI , http://folk.uio.no/botnen/intel/vt/reference/vc50.htm // so at least 2x speedup would be achieved (only on P4+ CPUs) // Athlon XP does not support SSE2 and SSE can only do 2 float to int using // see http://folk.uio.no/botnen/intel/vt/reference/vc57.htm intindex1 = double_to_int(fullindex1); intindex2 = double_to_int(fullindex2); intindex3 = double_to_int(fullindex3); intindex4 = double_to_int(fullindex4); // can be parallelized using SSE (doing 4 ops per instruction) fract1 = fullindex1 - intindex1; fract2 = fullindex2 - intindex2; fract3 = fullindex3 - intindex3; fract4 = fullindex4 - intindex4; // can be parallelized using SSE outputsamplebuf[0] =samplebuf[intindex1] + fract1 * (samplebuf[intindex1 + 1] - samplebuf[intindex1]); outputsamplebuf[1] =samplebuf[intindex2] + fract1 * (samplebuf[intindex2 + 1] - samplebuf[intindex2]); outputsamplebuf[2] =samplebuf[intindex3] + fract1 * (samplebuf[intindex3 + 1] - samplebuf[intindex3]); outputsamplebuf[3] =samplebuf[intindex4] + fract1 * (samplebuf[intindex4 + 1] - samplebuf[intindex4]); fullindex1 += 4.0*pitch; // increase fullindex1 by 4 times pitch because we processed 4 samples } The disadvantage is that you must keep pitch constant for 4 samples but this is not a big problem. (but in theory we could add a different pitch value to each fullindex1-4 variable so it would not be so hard to lift that kind of restriction). Eric what do you think ? can something like that be coded efficiently using SSE/SSE2 ? (I'd prefer SSE because the Athlon XP support that kind of instructions too while SSE2 is only supported by P4+ or AMD64 CPUs) regarding pure SSE math, try to compile this benchmark with gcc 3.3/3.4 and try to use -mfpmath=sse/sse2 you will see speed will suck compared to using the regular FPU. The intel icc will do less damage but it will still be slower than pure FPU code. http://www.linuxdj.com/benno/rspeed4.tgz Using SSE is not always a panacea for audio apps. cheers, Benno http://www.linuxsampler.org

Eric what do you think ? can something like that be coded efficiently using SSE/SSE2 ?

On Fri, 2 Jul 2004, Erik de Castro Lopo wrote: Would an opteron be any better at it?

Probably not. There are some algorithms which simply can't be vectorized.

On Tue, 29 Jun 2004 10:19:32 +0200 Benno Senoner &lt;sbenno(a)gardena.net&gt; wrote: Have you tried compiling your code with gcc-3.4? Do you have a test suite that will pick up if the above construct turns out wrong? Lets say that after the addition of increment, the value of fullindex in the 80 bit internal representation is 1.99999999999999999999999. Pass that number through lrint and you get 2 and subtract 2 from the 80 bit internal representation and you get -0.00000000000000000000001 which is excatly the sort of problem I was trying to avoid. <> I value correct-ness above speed :-).

lrintf() is portable (ISO C99 standard), FISTL is not.

At Mon, 28 Jun 2004 19:56:50 +1000, Erik de Castro Lopo wrote: I don't understand this lrint (floor ()) stuff. floor() returns a truncated integer value, so what's the point of calling lrint() on that?

Ah. Now I get to find all the places in my code that can benefit from that. If you assign a float value into an int variable, is that an implicit cast?

Good to know, thanks for the tip. Although, just using lrintf(val) would be wrong anyway because it would round up if fmod(val, 1.0) > 0.5, right?