Ruby versus Java threading?

ruby-talk
1

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. "

2

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

···

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. "

3

I'm sure I'll probably upset someone with this reply, but here goes...

Java threads are roughly equivalent to OS threads. Most JVMs will implement a Java thread on top of an OS thread. There is no guaranteed relationship there (just as there is not in .Net) but for practical purposes it is pretty much valid.

Ruby threads are very primitive compared to OS provided threads. In some respects the "threading" is more like the cooperative multi-tasking you found on early Atari ST, Windows (3.1) and Macintosh computers, where one thread/task could only resume when the current thread/task reached a point at which the OS could regain control (typically a yield() call or a GUI event dispatching call, etc - there really was a Win16 yield call if I remember correctly). That means it won't take advantage of hyper threaded or multi core CPUs.

The ruby thread switching is all done by the same OS thread and is done by a specific function in the ruby runtime (that you don't call, but the interpreter does call from certain operations). If that function doesn't get called (because the operations that call it are not called) threads don't get switched - call a long running C function and your ruby threads can't switch until the end of it. Thus the threading effect can be quite uneven - not pre-emptive like Unix/VMS/Windows operating systems.

If you doubt the above description download the Ruby source and go have a rummage (all the multi-threaded implementation stuff in the source is #if defined out).

For full blown threading I guess that won't happen until Ruby 2.0 (someone else please fill in the details there I haven't been following that enough) or the .Dot Net ruby versions (Microsoft and other) where threading is provided by the underlying .Net Common Language Runtime.

Re: Your Java vs Ruby comment. My preferred languages are C++, assembly and Ruby. Java always felt like working in a straight-jacket - no access to the underlying hardware and a restricted way of expressing things. With Ruby I still have no access to the hardware but a nice language to do it in. I worked with Java from 1996 until 2005. I'm very pleased I no longer work with Java.

Even if Ruby (or Python) don't end up being the dominant scripting/agile/flexible language in X years time your experience using it will prepare you for whatever it is that does end up being dominant.

Stephen

···

In message <1183016886.465541.8790@n2g2000hse.googlegroups.com>, surf <surfunbear@yahoo.com> writes

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 ?

--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting
Reg Office: 24 Windmill Walk, Sutton, Ely, Cambs CB6 2NH.

4

I see you already have some great answers, but this might be worth a read for you:

James Edward Gray II

···

On Jun 28, 2007, at 2:50 AM, 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 ?

5

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. "

Well, you can use JRuby. Which is a Ruby implementation that runs on
top of a JVM and uses the threads provided by the JVM (the Java ones).

···

--
"Es también nuestra intención erradicar la corrupción, ofreciendo como
norma la honestidad, la idoneidad y la eficiencia. Con madurez y
sentido de unidad es fácil pensar en la recomposición del ser
argentino. Ese ser argentino, basado en madurez y en sentido de
unidad, permitirá inspirar para elevarnos por encima de la miseria que
la antinomia nos ha planteado, para dejar, de una vez por todas, ese
ser "anti" y ser, de una vez por todas, "pro": "Pro argentinos""

Jorge Rafael Videla para el 25 de mayo de 1976

6

With Ruby, you tend to do parallel operations with processes instead
of threads (fastcgi workers with rails, for examples).

It's only a problem if you insist on trying to solve all problems with threads.

···

On 28/06/07, surf <surfunbear@yahoo.com> wrote:

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.

--
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/

7

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.