Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

NEW REGISTRATIONS - please contact us if you wish to register on the forum

Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright

Ruby vs Green

For general discussion related FlowStone

Ruby vs Green

Postby stw » Mon Nov 26, 2012 3:18 pm

So i spent some time to have a look at the new FS capabilitys compared to RIP SM. Though i really like to dive deeper into ruby i'm right at the point where i ask myself which parts of my old projects are worth to be converted into ruby and what benefits could i get from it?
My conclusion so far: As long as i don't need any additional functionality introduced by ruby i'll get nothing than much work with just some educational values.
One of my hopes was that i could decrease at least some GUI CPU cycles but it seems that ruby can't do any better than a more or less trigger optimized green version.
So the simple question is, am i right with my assumption or do i overlook some obvious aspects? Does it make any sense to "recode" green modules with ruby? Or even worse... could ruby at the actual point of implementation cause some unwanted side effects?
stw
 
Posts: 111
Joined: Tue Jul 13, 2010 11:09 am

Re: Ruby vs Green

Postby trogluddite » Mon Nov 26, 2012 4:51 pm

stw wrote:One of my hopes was that i could decrease at least some GUI CPU cycles but it seems that ruby can't do any better than a more or less trigger optimized green version.

A 'more' optimised green is about comparable, from what I've seen so far; but not the 'less' optimised case - infuzion's super-optimised green knob control seems to use about the same CPU as the stock Ruby knob with no optimisations at all. So unless you are absolutely sure that your 'green' is well and truly optimised to death, the chances are Ruby will give slightly better performance.
But this is only for a relatively simple case - in situations where arrays or draw loops are being iterated, in particular, the performance advantage seems to be much greater.
And how does one judge whether a 'green' design is optimal or not? - in all but the simplest cases, I don't think I'm ever quite sure, despite the amount of time I've spent with SM. OTOH with Ruby it is much more likely that you can spot a rogue redraw because of the nice linear interpretation of the instructions.
So whether the effort of translating exisiting routines to Ruby is worthwhile will probably depend a lot on the complexity of what you aim to replace. It's certainly not a 'magic bullet' - the real advantage comes from the things that Ruby can do that green cannot - I'd certainly consider replacing anything that makes heavy use of arrays, integer loops or draw loops, but for trivial operations that are not called often, I don't think I'd bother.
I'd say, suck it and see - check it out on a couple of your own designs, and see if the difference in performance justfies the amount of effort it seems to need.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1730
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK


Return to General

Who is online

Users browsing this forum: No registered users and 70 guests