when code component is consuming CPU?

[tester]

General question. When the code component is consuming CPU and when not?

In most cases, it is enough to use multiplexer/selector, so that the flow is rewired internally. But I noticed on some stuff (that is not using readouts), that even if outputs are offline - CPU consumption is still as if they were operating normally. So my question - what else (except these blue to green readouts) is using them in such cases? Mono4 prims? Something else?

[KG_is_back]

from what I can tell, anything that has the blue mono/mono4 input by default (pack/unpack, mono to green/frame, possibly even the mono delay primitive and code modules with monoin inputs). We would have to check that though.

[tester]

Okay, this is no rush. I just found blue leakage in my project, so this part seems to be fixed by now. Although I'm curious, whether on mono4 processing - is possible to get back CPU from unused channels.

[tulamide]

The user guide makes it clear enough. It says that a mono section is processing constantly (no matter if signals arrive or not). So everything mono (incl. mono4) processes from the moment it is in the schematic. Since mono4 is four times quicker when using all four streams, you could get back some processing load by combining single monos to mono4. But the overall savings won't be as much as you might think, since a few cycles are used for packing/unpacking. So better not use it just for one mono stream.

[tester]

It's not the point.

Some time ago I played with something (either wavetable oscillators or I don't remember what), and it appeared, that pushing things through mono4 wasn't faster than using 4x more single streams. And even more to say - mono4 version produced glitches which weren't there when using single (actually dual) streamed versions.

Another thing is, that there are ASM works here and on SM forum that are written for mono4 in slightly different ways (for example it's not possible to use them then as mono4 ins/outs).

If something uses 5% of CPU per unit, then at dozens of such 5%'s per schematic - it's worth to play a little bit with it.

[KG_is_back]

Okay, this is no rush. I just found blue leakage in my project, so this part seems to be fixed by now. Although I'm curious, whether on mono4 processing - is possible to get back CPU from unused channels.

You can. Most operations form code component are based on SSE operations which truly process all 4 channels in parallel, but there are a few that don't - they are calculated 4 types (once per each channel) and also usually consist of composite operations. Namely those are Pow(x,y), moving values from/to arrays, sine/cosine calculation, partial remainder (x%y). You may save quite a lot of CPU by stripping them down of parts that calculate the unused channels using the assembler. They are relatively easy to spot - just look for patterns that are repeated 4 times. Usually they use instructions like mov eax,Temp[0]; or fld Temp[0]; and similar operations that are not part of SSE.
Such instructions generally use quite a lot of CPU so deleting these parts from parts that process only mono signals or only some of the mono4 channels may greatly improve CPU.

Attached schematic shows that for the power instruction from code block. On my machine the Code version shows 3.6% CPU and the reduced version 1.1%

The user guide makes it clear enough. It says that a mono section is processing constantly (no matter if signals arrive or not). So everything mono (incl. mono4) processes from the moment it is in the schematic. Since mono4 is four times quicker when using all four streams, you could get back some processing load by combining single monos to mono4. But the overall savings won't be as much as you might think, since a few cycles are used for packing/unpacking. So better not use it just for one mono stream.

That is not completely true. Mono streams are actually compiled (and therefore used in processing) ONLY and only if they are connected to some sort of output primitive. You may easily observe that in "mono to poly" module. It uses mono write primitive to write data onto memory and read it in poly. However, the mono write is also connected to "mono to float" prim, to make it compile. If you remove this mono to float, the "mono to poly" module will stop working.

Both pack and unpack primitives use very little CPU - roughly the same as adding 4values within code component. adding,subtracting,multiplying and copying values takes very little CPU - division and square root may take 5 to 10 times more CPU and pow(x,y) even 100times more.

[tulamide]

That is not completely true. Mono streams are actually compiled (and therefore used in processing) ONLY and only if they are connected to some sort of output primitive. You may easily observe that in "mono to poly" module. It uses mono write primitive to write data onto memory and read it in poly. However, the mono write is also connected to "mono to float" prim, to make it compile. If you remove this mono to float, the "mono to poly" module will stop working.

Both pack and unpack primitives use very little CPU - roughly the same as adding 4values within code component. adding,subtracting,multiplying and copying values takes very little CPU - division and square root may take 5 to 10 times more CPU and pow(x,y) even 100times more.

I see. Thanks for pointing it out. And for the example

To the last point: What I meant was that mono4 just works in parallel for up to 4 streams. If there is only one stream, you gain no advantage. And with the overhead of packing/unpacking it would even be a few cycles slower, if there is only one stream. Or is this a false interpretation?

[tester]

I'm pushing multiple filters through mono4 setups, but not all are in use at once. But instead of turning on/off individual filters (=CPU usage) - whole slot is turned on/off. While this is nothing very inportant (I probably need all 2x4 slot at once anyway), it reminded me, that in the past I saw situations in which "disabled" code blocks - used CPU. And I started to wonder - what are the options.

Thanks KG for tips.

[KG_is_back]

To the last point: What I meant was that mono4 just works in parallel for up to 4 streams. If there is only one stream, you gain no advantage. And with the overhead of packing/unpacking it would even be a few cycles slower, if there is only one stream. Or is this a false interpretation?

Oh, I misunderstood what you said. Yes, you are right, packing a single channel into mono4 is nonsense - you'd just use additional unnecessary CPU load for packing/unpacking and the rest of the code would just be exactly the same.

[tulamide]

I'm pushing multiple filters through mono4 setups, but not all are in use at once. But instead of turning on/off individual filters (=CPU usage) - whole slot is turned on/off. While this is nothing very inportant (I probably need all 2x4 slot at once anyway), it reminded me, that in the past I saw situations in which "disabled" code blocks - used CPU. And I started to wonder - what are the options.

Ah, now I understand. Well, for that situation my post indeed made not much sense