Code speed tester

[KG_is_back]

This helpful module will allow you to easily observe the CPU load of your stream code. It basically creates multiple copies of your code using poly, to push CPU load into observable ranges. You may specify the No. of instances to create as well as compare load of schematic with your code bypassed.
http://flowstone.guru/downloads/code-speed-tester/

[martinvicanek]

Sounds like a very useful device. Can't wait to try it out!

[Exo]

Yes thanks KG, sounds very handy. Not at my PC to try it out until tomorrow.

[KG_is_back]

It just came to my mind, while I was testing how much CPU individual assembly instructions take. Off course, this is very machine specific, so I will have to create a test schematic and ask FS users (you) to test it. Then we can make some FS related opcode reference list which will include descriptions of the functions, examples of their use and CPU load tables. This will hopefully steepen the learning curve for new guys and also give "all in one place" reference for us old guys (more in depth than the list on SM wiki).

I'm also testing some other stuff like pipelining (when processor can start new instructions before the last one is finished, if they don't use each others output for input) and data bypass penalties (a delay it takes your CPU to switch between integer and floating point math units). "Fortunately" FS uses practically only single-precision-float operations which rarely support pipelining (assuming from processor specification papers I've checked) and have no bypass delays when used after each other. So space for optimizing in that area is small. Still in extreme cases the difference can be up to 20-50% on some machines.

[megique]

Hi KG,

I'm using your Code Speed Tester and it proves very useful so thanks for sharing! I do have a hard time though figuring what does it actually do. Let's assume this is my schematic:

my-module => code speed tester

And let's assume that my-module is a simple filter and i usually would pass some inputs to this filter. For the case of this schematic we don't pass the inputs to my-module though and it still somehow shows me some CPU usage when I turn on the tester component. How is this happening? I see you're generating a bunch of MIDI notes in the Ruby component but I don't understand how are they being processed by the filter in the end? I assume some of the magic happens when you add two Poly streams in your component...? I'd be grateful for some explanation.

Cheers!

[KG_is_back]

Hello megique!
The tester takes advantage of how flowstone handles poly.
Flowstone streams happen in two separate ways. Mono is active whenever is connected to some output (be it soundcard or mono to float-type of prim). It also uses SSE, which means, the same code processes 4channels at a time using the same code (mono and mono4 are actually identical, except the way the connector links look). Poly is implemented in different way. When you create an voice (using midi to poly module) each voice uses one of the 4 SSE channels (group of 4 voices are executed using the same code). That means 1-4 voices have some CPU usage, 5-8 have double the CPU usage etc.
My module takes advantage of this. When you connect a module to the tester, is uses it as a code for poly section. For each instance (number of instances may be selected on front panel) it creates group of 4 voices = 1copy of the code is running. This way you can double/tripple/quadruple... the execution of your code.
Keep in mind, that the output of the code may not be the correct one (especially if your code uses some funky mono4 processing), but the CPU usage will match (unless it's dependent on the input in some way).

To make things clear, in Flowstone, code is executed if it's connected to at least one output in some way(output may be soundcard output prim or some mono-to-float prim).
If you need to pass some specific input to your code, use mono-to-poly module. However, keep in mind that the input source will count for the CPU usage.

[megique]

Thanks for the answer! Unfortunately I'm still confused on how is this exactly happening, this is the part that I don't understand:

When you connect a module to the tester, is uses it as a code for poly section.

How exactly does it use my module as a code for poly section? I cannot figure out how does the code in my module know how many voices is it supposed to process since the voices are created much later in the schematic...

Just for the record I know about SSE and I understand the part which you described about the number of instances/voices and I understand the code you wrote in your tester in the Ruby module. It's just the part where the voices you create are miraculously being processed by my code is a mystery for me.

[KG_is_back]

Let me put it this way...

If your module is connected to a mono output (any prim that specifically expects mono and converts it in any way, for example soundcard output or mono-to-float prim) automatically becomes mono-part of your schematic.
If your module is connected to a poly-to-mono prim it is automatically a poly-part of your schematic. As I explained earlier, poly is being processed in groups of 4 voices - 0-voices ~ the code is not executed; 1-4 voices ~ the code is executed once; 5-8 ~ the code is executed twice (as two separate copies). poly-to-mono prim then simply sums the outputs of all voices and sends them out as regular mono (automatically outputting zero if no voices are active).

Midi-to-poly module simply triggers the voices to become active.

Little insight on how flowstone works under the hood. The entire mono part (all that is connected via blue connectors that lead to an output) of your schematic is compiled into a single bunch of machine code. Also all poly sections are compiled into one bunch of machine code the very same way (when you connect your module to the tester poly-input, you force it to become part of that code). The variables are stored separately. Processing is simply done by applying the machine code on the variables. In case of mono, these variables are initialized on every re-compilation of the code. In case of poly, they are initialized with the voice and are deleted once the voice is killed.

Flowstone has several types of stream connectors, which denote if the module/prim can be used in mono and/or poly:
1. black stream - modules/prims with black stream can be connected both to poly and mono and they supposedly process all 4 SSE channels in the same way. If you connected them to mono the imediately become white or blue, to prevent you from connecting mono to poly and vice versa, because they are handled differenty (as mentioned above).
2. white stream - is a part of poly section (usually because it's connected to poly-to-mono prim).
3. blue "mono" and "mono4" streams - they are connected to soundcard output or mono-to-float prim or they process the SSE channels in different way, so they wouldn't work properly in poly.

Hopefully this explanation is clear enough...