M. Edward (Ed) Borasky
6/28/2007 1:38:00 PM
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.