From the original SynthMaker forum (2004–2014), with its members’ names and dates.
oleg_t ·
I am new in making synths and stuff, but slowly I`m learning. What did I miss in my example? I`m comparing two frequnecy-normalizedFrequency modules, one - standart with primitives, other builded by myself - with assembler code. The second one written in ASM is ~50% slower than the first one. What am I missing here?
osm download here http://www.box.net/shared/rhftc9ibfl
treacherousumbrella ·
In your ASM version, 2/SR is calculated once per sample, whereas in the other version you have used green maths for this which does not run at sample rate. The green data types will only perform the calculation when an input value changes.
trogluddite ·
Hi there Oleg, welcome to the forum.
The reason for the difference is because of the way that the stream (white and blue) parts work differently to the triggered (green) parts of a schematic.
Green parts of the schematic are only calculated when 'triggered' - this is usually when an input value changes because you type in a number, move a knob, receive MIDI, etc. - for example, changing the float number two in the top sample rate calculation would cause the green division to happen. But the green division would only happen once when you make the change - after that the divide goes to sleep until another change wakes it up - and the result of the calculation then gets passed to the white stream as a constant value.
In stream parts (white/blue/code & assembly), the calculation is done for every single sample - and since division is a greedy instruction for the CPU, that makes the big difference that you see in the CPU load.
This is a clue how to get the best from SynthMaker - only use streams/code etc. for things which must be done at the full sampling rate - maths for controls, or fixed constants, or very slow changes are best done using the green primitives.
oleg_t ·
So in my ASM version 2/SR is calculated all the time. my conclusion - it seems that there`s no practical use if I`m using asm dealing with green math. Probably the best is I could use ASM when multiplying input (frequency) with green math output... Correct me if i`m thinking wrong 😉
UPD: thank you for your replies. while I was figuring out first one, the second one agrees with my understanding 😉
UPD2: yes.. it really works. Just multiplying frequency with green math calculated output (2/SR) I got slightly better result 😀 5%
trogluddite ·
Yes, you have that exactly right. It can save a lot of CPU when there are parts of a design that are OK to calculate in 'slow motion'. The only caveat it that the green parts don't have very accurate timing - the triggers can only be about 100 per second, and the timing varies with CPU load - so green is not good if you need accurate synchronisation.
djbrynte ·
It seems like ASM not always are faster. I tested some things. ASM clip is not faster ten normal. I save cpu using normal stereo clip. instead of xmm0 and stuff ASM.
infuzion ·
djbrynte wrote: It seems like ASM not always are faster. I tested some things.
Yes, lots of testing is needed to make sure. 🙂
MichaelBenjamin ·
asm at first runs at the same cycles than code, you save by editing the result.
speed optimisations are: - removing unnecessary movaps - removing unnecessary variable storing - using masks for sign and abs and other stuff i dont know (why isnt that integrated into the compiler?) - shutting down on demand with jumps and having more control over hops in general - single channel code where sufficient - shuffling channels with shufps - some other asm commands that are not available in the codebox - some things i forgot
infuzion ·
infuzion wrote: djbrynte wrote: It seems like ASM not always are faster. I tested some things.
Yes, lots of testing is needed to make sure. 🙂
Yep, wasted an hour because I used only the CPU Cycle Analyser & not SM's CPU% readout to see if replacing a primitive with ASM was the best thing to do.
EDIT: sometimes the same ASM replacement is faster, sometimes slower. Strange...
MichaelBenjamin ·
i think the measurement is flaky, so you cant really tell, but obvious optimisations should be always faster.
infuzion ·
MichaelBenjamin wrote: i think the measurement is flaky, so you cant really tell, but obvious optimisations should be always faster.
SM's CPU% seemed to coordinate well with Live7's CPU meter.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker