Avoiding uneeded calculations

trogluddite · 22 Jun 2012

rocko wrote: while others are being calculated all the time:

Not so... You have connected everything perfectly - when the outputs from the little 'shapes' modules are disconnected (not routed through the selector), they will shut down. So, combined with the hopping, you have already optimised this part of your design very well. This is always the way to make stream modules go to sleep - block the routing from all of the outputs and they will do it automatically. What is sometimes confusing is that if you connect e.g. analyser, readout, etc., those things will wake the module up again (a display to show the stream is equivalent to a live audio connection) - so there is no way to 'see' the saving for an individual module, you can only analyse the whole thing and guess which parts are 'awake' or 'asleep'

rocko · 22 Jun 2012

HI,

Thanks for the fast response, I'll investigate into this, as I was sure to have found a contradicting case - but I guess I was wrong.

Anyway - god bless SM 😉 Just give us 64bit 😉

Rocko

CoreStyler · 22 Jun 2012

rocko wrote: HI,

Thanks for the fast response, I'll investigate into this, as I was sure to have found a contradicting case - but I guess I was wrong.

Anyway - god bless SM 😉 Just give us 64bit 😉

Rocko

True give us 64bit!

trogluddite · 23 Jun 2012

rocko wrote: I was sure to have found a contradicting case - but I guess I was wrong.

None of this is documented officially - us 'old timers' can advise only on the basis of our previous experience, but we are not omniscient. SM is unpredictable sometimes, because the documentation is so vague about the 'rules' - if you think you have found something odd, post your schematic - there's always the chance that you have found something bizarre that has never been noticed before.

rocko · 27 Jun 2012

Hi,

I have just investigated into this again and you (Trog & CoreStylers) are right.

I created some CPU demanding modules and verified that CPU is not changed once these modules are ommited from main module - while their output is not "selected".

Nice !

infuzion · 27 Jun 2012

trogluddite wrote: rocko wrote: while others are being calculated all the time:

Not so...You have connected everything perfectly - when the outputs from the little 'shapes' modules are disconnected (not routed through the selector), they will shut down. So, combined with the hopping, you have already optimized this part of your design very well. This is always the way to make stream modules go to sleep

Technically, SM re-compiles the ASM code when you change the Selector connected in an audio stream. So, a non-connected/switched-off code is not even compiled/existing in the live code.

Pro tip: If your filter values are static are rarely changed (eg only switched, not hooked into a knob), then calculate them all in green; they'll only use CPU for when they are calculated once, & not at every sample.

rocko · 28 Jun 2012

Infuzion hi,

Thanks for your comment - you have hit the 'sweet spot' as my next goal is to decrease CPU usage.

So this code is part of an IIR EQ I'm building just for fun. So, the biquad coefficients have to change from time to time. For this reason - I can not do it in green code.

I have used hop function to a large extent hop(4096) and it naturally decreases CPU. As far as I understand - this means that the calculation is done only at (S_Rate / 4096).

However I'm still looking for a way to make the calculation only when a new parameter is dialed.

What are the suggested options to use code (not green) but "ignite it" only when a parameter is changed?

Thanks, Rocko

rocko · 28 Jun 2012

Hi,

I'm considering another different approach.

The problem with "green" is not the speed of calculation but synchronization [that is the main reason I use "code" with hop(4096)]. So, when moving the dials around, the green calaculation can output a non-full set of coefficients, were some are newly computed and some are the old ones. At this point the system filter shape is compltely unknown and unpredictable which prodcues clicks pops, etc.

So, maybe I can run all calculation in green and build a way to pass them on, only when all 5 coeffeicients have completly changed?

Any advice is welcomed - but I'm actually looking for a "triggered code" or "synchronized green" calculation.

Rocko

cyto · 28 Jun 2012

rocko wrote: However I'm still looking for a way to make the calculation only when a new parameter is dialed.

What are the suggested options to use code (not green) but "ignite it" only when a parameter is changed?

How versed are you in assembly? This is very do-able in asm, using the "jc" opcodes. You basically take your input value and store it in a variable, then on the next sample test the stored value against the new input to see if it has changed. Use this to trigger a subroutine. I do this all the time. Quite handy. If you're up for it, I'll post an example.

EDIT: here's a quick little "shell" of change test...

streamin in;

movaps xmm0,in;//new value movaps xmm1,hold;//old value cmpps xmm1,xmm0,0;//test for difference movaps hold,xmm0;//save for later movaps test,xmm1;//true (not zero) if no change mov eax,test[0]; cmp eax,0; jnz subRoutine;

//put your calcs here //they will only run on change

subRoutine:

Keep in mind, that this only tests the first SSE channel, so if you have "packed" or poly data, you'll need to adapt it. Also, obviously this only tests one value. Since the test uses a bool, you can use "or" logic to test for changes in multiple inputs.

-cyto

rocko · 28 Jun 2012

Hi,

Sorry to admit that assembly is an unknown territory for me.

But - I guess I better start digging into it if I like SMing and I do...

I'll go and learn some ASM on the net somewhere and get back to this.

For the time being - if I just copy paste this to my code, will it work? Should I save my code as ASM first and then copy paste this? Or isn't there a way to use it for a none ASM knolwedgeable guy like myself?

Thanks

rocko · 28 Jun 2012

Hi,

sorry - couldn't work with it.

If you're up for it, I'll post an example.

Please post example if you have the time 😉

cyto · 29 Jun 2012

hey rocko.

Yeah, asm can be kinda intimidating and if you're not comfortable with it, it all looks like alien garble. The good news is, once you make the decision to jump in, it's not as bad as it seems. In fact, it's quite logical. I put off learning it for awhile, but after making the plunge, I very rarely use the "code" box or the stream primitives anymore. It seems very natural to me. I'd like to help you out with your project, but I'm afraid that any solution would be very application specific (ie. you couldn't just cut and paste into your code). If you post (or PM me) a working osm, I'll gladly look at it. Or if you're just using standard RBJ coeff calculations, I may be able to post some "ready-mades" here for you to use. Though, I am somewhat busy right now, and it may be awhile (if you talk to people that work with me "privately", you'll learn that I have a tendency to disappear for extended lengths of time 🙂 ). But if you're patient, I'll see what I can do or maybe someone else will chime in.

-cyto

rocko · 29 Jun 2012

Cyto hi,

Thank you very much for your time and patience !

I think this will be a useful 'trick' for many, so I'll start a new post and upload an RBJ based example.

If you could go on with it and explain this trick better - that would be great !

Triggering Code

Rocko

infuzion · 1 Jul 2012

rocko wrote: The problem with "green" is not the speed of calculation but synchronization... So, when moving the dials around, the green calaculation can output a non-full set of coefficients, were some are newly computed and some are the old ones.

That would be a green-linking issue.

trogluddite · 2 Jul 2012

infuzion wrote: That would be a green-linking issue

Not necessarily - the same problem came up with some of the alternative sine oscillators. The green and stream threads are not synchronised at all, so it is possible for code to read the green values 'mid flurry'. So if a single green trigger is split into multiple parallel calculations, the results don't always hit the code on the same sample.

infuzion · 21 Jul 2012

Those dang flurries!