Topher Cyll

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.

posted on: 06/28/2006 | path: /tech