Ruby Speed Question

[billv]

Myco pointed out before that If i use multiple ruby outs, FS would be faster on one link.
So if i have all the outs on one output like this...is FS still faster?...

ScreenShot250.png (10.53 KiB) Viewed 19008 times

I presuming that "parse" means loosly to "push the data"...
So what happens here on this link....any delay for parsing???....
or do all receiving inputs get exactly the same signal.

I guess in a way I'm trying to "eliminate" trigger order........

Here's the original question...

Is it better off to take something like this...

And turn it into this....

So who's faster..Ruby or FS
Myco:
The FS version is faster, because every trigger on a Ruby input invokes the Ruby parser/interpreter, which is slower than native machine code.

[RJHollins]

Though I can't directly provide any answer ... I thought I recall a 'timing' module that might have been designed to test the execution time of a routine.

Might have been something from TROG's toolkit, or maybe MyCo's utility [?].
This may have been from the SM forum.

Just an idea ...

[Nubeat7]

why not using wireless links? and does this make a difference? are there linkorder on wireless links too?

[billv]

are there linkorder on wireless links too

I'm pretty sure there is...(correct if wrong)
.......you can see the linkorder using the new "TAB" feature on wireless links....

[trogluddite]

Which is faster - well, that's very likely to depend on what you are trying to do and which components you are using - but MyCo is right, Ruby is not a 'silver bullet' for better performance.
First a couple of answers to the direct questions...

What is parsing?
'Parsing' is the act of taking the written code and translating into actual machine instructions. The difference is most clear if you compare Ruby to DSP code or assembly...
For DSP code and assembly, the code gets 'compiled' - actually turned into a complete set of machine instructions - and those instruction just get executed without FS having to ever look at the written code again (until you change it!). So compiled code is parsed, but only once, and "off line" long before the code actually runs.
In contrast, Ruby actually processes your written instructions at run time - turning them afresh into machine commands each time around. Well, it is a little cleverer than that - it uses something called 'byte-code'. Rather than always having to scan the actual characters you write down, it turns words that it knows are commands into 'codes' to speed up the execution, and similarly for 'symbols' such as variable names. But it is still a much slower process than simply running a chunk of ready compiled machine instructions.
Within a primitive, of course, everything is already compiled by DSPr, so there is no parsing at all - and they can dig inside the CPU instructions much deeper than we can, so primitives can be very optimised.

Do wireless have a trigger order?
Yes, but it is much, much harder to manage than for 'spaghetti' links. The order is decided by the order that you build the links, and once built, the only way to change it is to delete them and rebuild! IMHO, they are best used for 'preference' type settings that won't change much, or as single links to reach hard to get places.


Re: Speed comparison...

In the case of the examples above, I would guess that the 'speed' order would be something like...

Fastest - Just splitting the green trigger - there's no translation from 'green' to 'Ruby' and back again, and no parsing.
Medium Fast - Single 'green' Ruby output - there's only one translations Ruby->green, and then the trigger goes on its merry way. The version where it is a single 'Ruby value' output would only be used if you were sending the signal only to other Ruby components - if each one needed turning back into green later on, it would be very slow.
Slowest - Ruby with many trigger outputs. All of those 'output,x,y' lines need parsing individually, and then every output needs translating back into green - again one at a time. You should only do this if the outputs really do represent independent signals that happen under different circumstances, and there is some reason that you must use Ruby to get the code working.

An example of where Ruby might be faster is when you are working on very large arrays or complex data structures - Ruby has many array operations that can be done with just a single command (e.g. sorting and filtering), where 'green' would need dozens of components, all contributing to a massive number of triggers to look after. But even then, it's not guaranteed that Ruby would be faster, it will depend on the complexity of the operation, and how good you are at optimising green triggers (using 'trigger blockers etc.)
If accurate timing is more important than CPU load, then naturally, you should use Ruby for its sample locked clock - and there are some things Ruby can do that would be nearly impossible in 'green'!

One time that you should ALWAYS heed MyCo's advice is when there is a something you need to do in 'green', and it can be done using just a handful of primitives. Ruby will be WAY slower than the compiled code inside a primitive, and translating green->Ruby->green will just slow it down even more.

[tester]

In other words: don't make dummy ruby trigger pass through, otherwise you loose 0.000000000000000000000000001% of your CPU speed.

Generally, the performance questions should probably placed in a context. "Ruby in context of", otherwise you may get answers like above?

[billv]

First a couple of answers to the direct questions.

Thanks trog.....lots of details to think about there.....

Fastest - Just splitting the green trigger - there's no translation from 'green' to 'Ruby' and back again, and no parsing.

Look up in the sky, is it a bird, is it a plane....no it's Supergreen......da da dada da da da

Generally, the performance questions should probably placed in a context.

Yeh...I'm bad...sorry.........there's just so many different context here......

otherwise you may get answers like above?

Was a great answer though......Trog can still see through my dodgy questions....

Ok, here's a context...
There should be no delays with something like this...yes????

ScreenShot251.png (22.77 KiB) Viewed 18970 times

[billv]

Ok, here's a context...

...I didn't explain the "context' at all did I....?

Idea with above picture is for splitting up the "bool to false' trigger from the stop/start.
My synth relies heavily on this "bool to false' trigger....
Won't help for standalone but could tighten this area up for VST....

[trogluddite]

In other words: don't make dummy ruby trigger pass through, otherwise you loose 0.000000000000000000000000001% of your CPU speed.

He he
But remember also what MyCo mentioned a little while ago...
Because Ruby and Green are of different threads, there is also a time cost for translating Green->Ruby->Green - around 1ms per 'translation' - of much more significance than a small CPU increase.
...and that was from a conversation he had with Malc, so likely much more accurate that my wild guesswork!!