This post originated from an RSS feed registered with Ruby Buzz
by Christopher Cyll.
Original Post: JRuby gets Gems
Feed Title: Topher Cyll
Feed URL: http://feeds.feedburner.com/cyll
Feed Description: I'm not too worried about it. Ruby and programming languages.
There's a great
post by Charles Nutter about JRuby and Ruby Gems. He talks about
two problems.
One problem (and this affects a lot of languages, not just Ruby), is
that "pure" libraries have often been replaced with libraries
implemented in C for performance. This is great during the dark ages,
because it helps address the speed issues that almost all fledgling
languages have. But as soon as these languages are targetted at new
runtimes or get compilers or JITs, it becomes a problem.
For example, in the amazing Python Psyco library (a JIT for Python
that delivers the kind of speed us Rubyists can only lust over), calls
to "map" and "filter" are actually slower because they were
implemented in C (for performance) and therefore trigger the C code
<--> JIT code penalty when passed in JITed higher order
functions than they would be if they were implemented in pure Python.
The Smalltalkers really got this right, and almost everything in
Squeak is basically written in Smalltalk (or an easily compilable
subset known as SLang). There are a few issues there, as well, but
damn it's cool.
The second problem discussed is that JRuby has choosen to implement
rthreads using Java native threads, which are in turn implemented with
OS threads. Or at least that's my understanding. rthreads, the
standard Ruby thread library is a lightweight userland implementation
that accordingly can't take advantage of multiprocesser machines.
Cheap threads make certain programming strategies feasible. For
example the Ruby net/http library makes use of a timing library
through several layers of code. This library starts a new thread for
each wait. When you are using non-lightweight native threads, this has
a serious performance cost -- apparently to the point where it's
unclear if the app is even making forward progress.
Just a further reminder that APIs are more than method
signatures. They also include the behavior and properties of those
methods and sometimes even their implementations.
Actually, it makes me a little curious why JRuby didn't implemented
userland threads, ala rthreads, for the Thread module and then also
provide an additional module, perhaps called NativeThread. But I'm
sure there's a good reason, since JRuby consistently impresses me.
Previous Topic
