Optimized Delays (PART 2)

aliasant · 1 May 2009

Is it samplerate independent?

Tzarls · 1 May 2009

Well, I think the input is in samples, so as long as you adjust the number of samples for the active samplerate, everything should work ok.

MyCo · 1 May 2009

it is not directly samplerate dependent, but it has a buffer that is max. 1 second long for 44,1kHz, 2 seconds for 22,05kHz... So if you need long delays for high samplerates you have to adjust this, but it's the same for all delay code modules.

MyCo · 1 May 2009

Here is the same optimization for the non-interpolated delay version:

streamin in; streamout out; streamin delay;

int arrayindex=0; float index=0; float F1=1.0; float mem[44100];

// move index by one sample and clip it movaps xmm0,index; addps xmm0,F1;

movaps xmm1,xmm0; cmpps xmm1,delay,1; andps xmm0,xmm1;

// write "in" into mem[index] fld index[0];fistp arrayindex[0]; fld index[1];fistp arrayindex[1]; fld index[2];fistp arrayindex[2]; fld index[3];fistp arrayindex[3];

push eax; mov eax,arrayindex[0];shl eax,4; fld in[0];fstp mem[eax]; mov eax,arrayindex[1];shl eax,4;add eax,4; fld in[1];fstp mem[eax]; mov eax,arrayindex[2];shl eax,4;add eax,8; fld in[2];fstp mem[eax]; mov eax,arrayindex[3];shl eax,4;add eax,12;fld in[3];fstp mem[eax];

// read mem[index] into out movaps index,xmm0; fld index[0];fistp arrayindex[0]; fld index[1];fistp arrayindex[1]; fld index[2];fistp arrayindex[2]; fld index[3];fistp arrayindex[3];

mov eax,arrayindex[0];shl eax,4; fld mem[eax];fstp out[0]; mov eax,arrayindex[1];shl eax,4;add eax,4; fld mem[eax];fstp out[1]; mov eax,arrayindex[2];shl eax,4;add eax,8; fld mem[eax];fstp out[2]; mov eax,arrayindex[3];shl eax,4;add eax,12;fld mem[eax];fstp out[3]; pop eax;

It saves ~26 Cycles which is around ~39% of the CPU time. This improvements are just made by reordering the code, what's a little bit curious...

aliasant · 1 May 2009

Great stuff Myco.

Did you do the rearranging in the original code and then optimized it in asm or did you do the alterations directly in the asm code?

MyCo · 1 May 2009

I did it directly... I've found out, that the advantage doesn't work everytime, I don't know why... eg. in the Chorus it doesn't work but in the Reverb it does.

Tom7777 · 2 May 2009

These are nice thanks, i did some quick tests with the default example changing a delay in the delay module and with SMs cpu reader i got -

Standard coded delay = 4.8-5% Standard coded delay replacement = 4.6%

Interpolated Delay = 5.7% Interpolated Delay replacement = 4.9-5.2%

Standard SM Delay = 4.2-4.3% (no stream modulation like others just int input)

It's annoying to test cpu though well in SM, none of the current cpu tools are that reliable really i find.

Nu Audio Science · 2 May 2009

Brilliant stuff

NAS

infuzion · 3 May 2009

Tom7777 wrote: It's annoying to test cpu though well in SM, none of the current cpu tools are that reliable really I find.

Best bet is to copy it 4-16 times, & link them together or sum them. Then differences become wider.

MichaelBenjamin · 3 May 2009

thanks myco. i changed a bit at start so F1 F0 and maxdelay have their own xmm register, saves 13 cycles, or 7.7% here.

streamin in; streamin delay; streamout out;

float smIntVarTemp=0.0; int arrayindex=0; float index=0; float tmpfloat=0; float MAXDELAY=44100; float F0P499999=0.499999; float F1=1; float F0=0; float rounder=8388611; float mem[44100];

// split delay into int(xmm0) and frac(xmm1) movaps xmm0,delay; movaps xmm1,xmm0; movaps xmm7,F1; movaps xmm6,F0; movaps xmm5,MAXDELAY; subps xmm0,F0P499999; addps xmm0,rounder; subps xmm0,rounder; subps xmm1,xmm0;

// calculate temp1(xmm2) & temp2(xmm0) movaps xmm2,index; subps xmm2,xmm0; movaps xmm0,xmm2; subps xmm0,xmm7;

// clip temp1 (xmm2) movaps xmm3,xmm2; cmpps xmm2,xmm6,1; andps xmm2,xmm5; addps xmm2,xmm3;

// clip temp2 (xmm0) movaps xmm3,xmm0; cmpps xmm0,xmm6,1; andps xmm0,xmm5; addps xmm0,xmm3;

// write in to mem[index] push eax; fld index[0];fistp arrayindex[0]; fld index[1];fistp arrayindex[1]; fld index[2];fistp arrayindex[2]; fld index[3];fistp arrayindex[3];

mov eax,arrayindex[0];shl eax,4; fld in[0];fstp mem[eax]; mov eax,arrayindex[1];shl eax,4;add eax,4; fld in[1];fstp mem[eax]; mov eax,arrayindex[2];shl eax,4;add eax,8; fld in[2];fstp mem[eax]; mov eax,arrayindex[3];shl eax,4;add eax,12;fld in[3];fstp mem[eax];

// read mem[temp1] into xmm2 movaps tmpfloat,xmm2; fld tmpfloat[0];fistp arrayindex[0]; fld tmpfloat[1];fistp arrayindex[1]; fld tmpfloat[2];fistp arrayindex[2]; fld tmpfloat[3];fistp arrayindex[3]; mov eax,arrayindex[0];shl eax,4; fld mem[eax];fstp smIntVarTemp[0]; mov eax,arrayindex[1];shl eax,4;add eax,4; fld mem[eax];fstp smIntVarTemp[1]; mov eax,arrayindex[2];shl eax,4;add eax,8; fld mem[eax];fstp smIntVarTemp[2]; mov eax,arrayindex[3];shl eax,4;add eax,12;fld mem[eax];fstp smIntVarTemp[3]; movaps xmm2,smIntVarTemp;

// read mem[temp2] into xmm0 movaps tmpfloat,xmm0; fld tmpfloat[0];fistp arrayindex[0]; fld tmpfloat[1];fistp arrayindex[1]; fld tmpfloat[2];fistp arrayindex[2]; fld tmpfloat[3];fistp arrayindex[3];

mov eax,arrayindex[0];shl eax,4; fld mem[eax];fstp smIntVarTemp[0]; mov eax,arrayindex[1];shl eax,4;add eax,4; fld mem[eax];fstp smIntVarTemp[1]; mov eax,arrayindex[2];shl eax,4;add eax,8; fld mem[eax];fstp smIntVarTemp[2]; mov eax,arrayindex[3];shl eax,4;add eax,12;fld mem[eax];fstp smIntVarTemp[3]; movaps xmm0,smIntVarTemp; pop eax;

// calculate interpolation factor frac(xmm3) movaps xmm3,xmm7; subps xmm3,xmm1; addps xmm1,xmm7; divps xmm3,xmm1;

// interpolate and save in output(out) subps xmm2,out; mulps xmm2,xmm3; addps xmm2,xmm0; movaps out,xmm2;

// move index by one sample and clip it movaps xmm0,index; addps xmm0,xmm7;

movaps xmm1,xmm0; cmpps xmm1,xmm5,1; andps xmm0,xmm1; movaps index,xmm0;

Dozius · 3 May 2009

MichaelBenjamin wrote: thanks myco. i changed a bit at start so F1 F0 and maxdelay have their own xmm register, saves 13 cycles, or 7.7% here.

With a single instance myco's seems to run faster but once you start stacking them up your modified version starts to win out. Shouldn't the benefit of moving those commonly used variables into an xmm reg be seen even in a single instance? Is it just the cpu tools acting up? I know, so many questions haha.

MichaelBenjamin · 3 May 2009

its consistent 13 cycles faster here with a single instance. i dont know, maybe its the processor (amd x2)? can some other people test this?

MyCo · 3 May 2009

I've tested realy everything on my CPU, the preloading (like MichaelBenjamin did), reordering the code, merging the SSE and x86 part, reordering the x86 (eg. 4 fld in series)... here is nothing faster than my versions above.

I also tried a trick that could be a little bit unstable but it should save 4... but it doesnt.... the trick should work like this: delete every "shl eax,4;" and just put a multiplication with 16 before the read block... It works on small buffer (44kHZ) but there is no better performance.

@MichaelBenjamin: in my test's your version uses 7 Cycles more. It's realy CPU dependent.

MichaelBenjamin · 3 May 2009

edit: so you got an intel processor? i attached the osm with the cpu analyser and my results

Dozius · 3 May 2009

Intel processor here. I'm getting the same results as Myco. The cpu analyzer you have there is newer than what I have. Where can I get the latest analysis toolkit? I thought I had the latest from the wiki.

MyCo · 3 May 2009

Yes, it's like Dozius said... A: 87 cycles B: 82 cycles

PS: The Analyser is newer than the one I used, the results are the same. BTW: One try to optimize the analyser could be to test sequential and not parallel.

aliasant · 3 May 2009

MichaelBenjamin wrote: edit: so you got an intel processor? i attached the osm with the cpu analyser and my results

I too have an Intel and B ( No preload) is faster by 6-7 cycles

stw · 3 May 2009

aliasant wrote: MichaelBenjamin wrote: edit: so you got an intel processor? i attached the osm with the cpu analyser and my results

I too have an Intel and B ( No preload) is faster by 6-7 cycles

dito

Tom7777 · 4 May 2009

That analyser is inacurate, i have tested and it can flip the results depending on when you plugin inputs in etc and there isn't really another decent one i have found either. I hope malc adds some decent testing tools sometime because currently they all give un-reliable readings.

infuzion · 5 May 2009

MichaelBenjamin wrote: I changed a bit at start so F1 F0 and maxdelay have their own xmm register, saves 13 cycles, or 7.7% here.

On my AMD64 single core laptop, I tried doing that with MyCo's version (I can't let him best me in ASM! 😉 )& I found only swapping F1for an XMM did I save 5 cycles; F0 & maxdelay XMMing slowed it down. You tend to get "free" memory loads as long is they're well interleaved. Also, if you load a register & do not use it for a while, that can waste cycles it seems sometimes.

MichaelBenjamin · 5 May 2009

i dont think the analyser is that inaccurate, instead its seems to be the different cpus showing varying results. so these optimisations finally seem to be quite useless since they are slower/faster depending on what cpu the code runs.

Tom7777 · 6 May 2009

All of them are inaccurate or at least on this computer, with that one when testing with your previous optimization osm it was telling me that the un-optimized version was better at times then after closing SM and opening it again it would tell me the optimized version was better, then flip the results again later. All the current tools are all far too jumpy and un-reliable on this computer, the only way i find to get good readings is to export out of SM and test in a host and thats really annoying to do. Im guessing it's down to the fact that the tools are built from modules rather than dedicated modules. Hopefully malc will make some decent tools for SM but i don't know when that will happen.