[Stk] Ruby extensions with STK

[David Michael]

Awesome Ed, now I really wish I had gone to RubyConf.
Thanks for the link, super valuable information in there.

That presentation sparks another thread of thought I have been having  
which is to explore the how one might use the STK/RtAudio with  
Erlang. The project I am working on is somewhat reliant on concurrent  
events - and multimachine concurrency would be outstanding. I am  
seriously green when it comes to Erlang, but I wonder if you might  
have any links, tips, or general ideas for how one might use the STK/ 
RtAudio or audio in general with Erlang. I am assuming that I would  
need to program my own modules.

David



On Dec 5, 2007, at 10:00 PM, M. Edward (Ed) Borasky wrote:
> I have spent a fair amount of time profiling the Ruby interpreter  
> -- see  http://rubyforge.org/docman/view.php/977/2705/Slides.pdf  
> for the gory details. Briefly:
>
> 1. For most low-level benchmarks (things like fibonacci, ackerman,  
> etc.) Ruby spends most of its time in the "inner interpreter" --  
> walking the syntax tree and dispatching method calls. And if you do  
> a lot of object creation and then remove references to the objects,  
> it spends a lot of time in the garbage collector.
>
> 2. There are three Ruby interpreters in common use and more in  
> progress. The one most people are familiar with is the standard one  
> that comes with most Linux distros, Ruby 1.8.6. Unless you compile  
> this yourself from source, as you would with Gentoo, chances are  
> you're getting something like 70 - 75 percent of the performance  
> you could be getting with an optimal "gcc" compile.
>
> The second Ruby interpreter is the one that will become Ruby 1.9  
> and is due out this Christmas. That one has an inner interpreter/ 
> virtual machine that's somewhere in the range of 3 - 6 times as  
> fast as "stock" Ruby. And the third is jRuby, a Ruby interpreter  
> and compiler built on the Java virtual machine by a couple of hard- 
> core performance tuners at Sun. The last benchmarks I saw from the  
> jRuby team showed them slightly faster than Ruby 1.9, and  
> significantly faster on multi-precision integer operations.
>
> There are three ways to optimize jRuby code:
>
> a. Let the JIT compiler do it.
> b. Compile Ruby with the Ahead-Of-Time compiler.
> c. Build libraries in Java and interface to them.
>
> In the case of Stk, since it's in C/C++, I don't think you'd be  
> able to use jRuby, but you should be able to use Ruby 1.9. But for  
> pure Ruby code, jRuby is worth looking at.
>
> 3. What would really be nice would be for someone to take the C/C++  
> Stk code and write SWIG interface files for it. What that gives you  
> is access to *all* the scripting languages -- Ruby, Python, Perl,  
> PHP, Lua, Pike, plus Java, a couple of Scheme and Lisp processors,  
> and R.
>
> 4. The three Ruby interpreters differ in how they handle threads,  
> if you're interested in using them. Ruby 1.8.6 uses so-called  
> "green" threads. The interpreter has its own scheduler and  
> dispatcher, so on a multi-core box, you only use one core per  
> instance of the Ruby interpreter. jRuby uses the threading  
> mechanisms in the Java Virtual Machine, which in turn use native  
> platform threading mechanisms. And Ruby 1.9 uses native platform  
> threading directly.