From: "M. Edward (Ed) Borasky" Date: 2007-06-28T22:38:03+09:00 Subject: Re: Ruby versus Java threading ? Robert Klemme wrote: > On 28.06.2007 09:48, surf wrote: >> This paragraph is part of the Java Performance tunning newsletter >> someone sent to me. I'm curious what the article means >> in regards to threads. My Ruby book has a section >> on threads, but I'm not sure if threads in Java are vastly different ? >> >> "So many people have been shouting at me that "Java has peaked, >> time to jump into Ruby" that it was time to find out about the >> hype. So I listened carefully to Ruby advocate Tim Bray. I found >> out that Ruby will reduce maintenenance costs because it takes a >> third of the lines to express the same things as in Java. That's a >> big plus. But I also found out that Ruby is not going to be able >> to handle any significant part of the hugely concurrent multi- >> threaded apps that I tend to deal with - apps that are the present >> and future of programming. Sounds pretty restrictive. I listened >> when Elliotte Harold tells me that Java developers are looking to >> Ruby and Rails - but then I spoke to some Java developers who have >> made that move, who tell me that it's a great system to get that >> initial prototype up and running, but that they end up with a mess >> when they try to advance the system. " > > The major - and crucial - difference between current Ruby's threads and > Java's threads is the implementation: Ruby currently uses green threads > (i.e. the interpreter itself implements them) while Java uses native > threads (i.e. the operating system does it via preemption). Consequences > are > > 1. Ruby can use at most one core and one CPU even on multiprocessor > systems. > > 2. If a long running C function is invoked from one thread all other > threads are blocked. > > It depends on the types of problems you are trying to solve whether this > will affect you in practice. Ruby threads do pretty well if you are > doing some concurrent IO (but not massive IO where you have a large > number of open file handles which each are served by their own thread) > because the interpreter will multiplex under the hood. > > The big advantage of green threads is that they are available on all > platforms even those where the OS does not support multithreading. But > since most OS support native threads nowadays this advantage is not so > important any more. > > Note that there are numerous efforts going on to provide a virtual > machine for Ruby, namely to make it run on top of a JVM. From there it > is likely that Ruby will support native threads in the near future so > the difference between Java threads and Ruby threads will at some point > shrink to a mere interface difference (i.e. you use threads differently > in Java and Ruby, for example, in Ruby a thread immediately starts on > creation while in Java you have to explicitly start it). > > Kind regards > > robert > > I'd say jRuby is the answer here -- it uses the JVM threads which in turn use the native OS threads. For a Java developer moving to Ruby and Rails, I'd say it's pretty much a slam dunk -- anything they're used to from the Java platform will be there if they need it.