DSP Robotics Support

Hi All,

There's been quite a bit of speculation about whether Ruby can out-perform the old green trigger system. The funky new stuff is cool - but should we re-write all our existing modules to get a turbo boost in performance?

So I decided to do a concrete test on a specific example - filling an array with some values that tale a moderate amount of maths to work out. As I had the timers out for this, the project also turned into a bit of challenge - to pit Ruby against Green, and also both of them against some tried and tested optimisation techniques.

So this is both a benchmark test and a tutorial - the same algorithm, in Ruby and in 'Green', optimised in parallel.

It's also a first outing for a new style of tutorial that I'm trying out - a schematic file, with various little widgets to help you find your way around, where there are live components to play with and not just a load of text to read (you will need to scroll a lot, though!)...


The readings in the time boxes when you load the schematic will be those from my Q6700 desktop - not exactly the newest machine around. You can change the size of the test in order to get meaningful results, as the time resolution is dependent on the trigger system and the real time clock resolution of 1ms.

Before testing with larger loop counts, be sure to make a backup of the file - large counts can cause a Ruby time-out which will lock out every single Ruby object in the schematic! It's a real PITA to unlock them all again, so a 'vanilla' file on disk is highly recommended!!

PS) Just tried it on my Atom N270 netbook - the times are obviously different, but the relative comparisons are very consistent with my 'big' machine.

I have some problems with viewing here. Seems that FS operates on very large workspace area, which is nearly impossible on my screen resolution (1024x768) to follow, when you hold the mouse on zoom window. Would not be better to split into smaller modules, let say 1 concept per module (like pages)?

tester wrote:mouse on zoom window.

Best to do it 'Photoshop style' - click in empty workspace with the spacebar held down, then drag! Much easier than the little thumbnails!

tester wrote:Would not be better to split into smaller modules,

Just an experiment - kind of was thinking more like reading a cartoon strip.

tester wrote: 1 concept per module

One concept - is Ruby faster?! You wanted to know, didn't you?

Yes, the advantage of you pointed out,
it is always connected to the garbage collection of variables and how it is handled by the ruby.
So this is true in a single session with a single trig, but what would happen with sessions with a high retrigering?

I think the performance is equal to MonoToFrame, where it proves its inefficiency.
perhaps because the garbage collection continues to erase the memory buffer allocated by the ruby,
and as many readings on it, it is clear that his performance and very low on repeated requests.

One concept - is Ruby faster?! You wanted to know, didn't you?

...modularizing within schematic.

Best to do it 'Photoshop style' - click in empty workspace with the spacebar held down, then drag! Much easier than the little thumbnails!

2 years and I still don't know the basics.

tester wrote:2 years and I still don't know the basics

He he - those are always the bits of the manual that I don't read because I want to get to the juicy stuff. I had SM for years before I found the "F-keys" bookmark thing.

tester wrote:...modularizing within schematic.

Maybe you could do a "modularising Trog's tutorial" tutorial?1

My machine is now in "guru meditation" state.
Exporting some video presentations/tutorials.

But I admit - your tutorial, this one - is good.
Especially helpful when large arrays are wandering over the green cables.

Tronic wrote:but what would happen with sessions with a high retrigering?

Yes, I would like to investigate that to - how does the GC handle itself when Ruby is given very little idle time - and distribution of resource between Ruby and Green when both are under stress.
The raw performance strikes me as about right for an OO scripting language- similar to Python etc.
Will be interesting to see if frames become more useful now that we have the .dll widget - as I understand it, that accesses the frame as raw binary from the audio buffers - no conversion to objects. Certainly the delay .dll demo seems to perform pretty well - very similar to the DSP coded one in the toolbox.

trogluddite wrote:Certainly the delay .dll demo seems to perform pretty well - very similar to the DSP coded one in the toolbox.

Duplicating the delay to 6 times, in idle without connecting other, the CPU is between 7-10%, at 96000Hz.
Trigering with the ruby and conversion to Frame? is the problem?
It would have been easier to have a Clockmaster API in the internal code for the audio portion of the DLL,
without using the ruby, which carries a trigger each time,
depending on the size of the buffer of your sound card, to transfer the DATA.