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 B… 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. "
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
Ruby can use at most one core and one CPU even on multiprocessor
systems.
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).
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 ?
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.
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 ?
I see you already have some great answers, but this might be worth a
read for you:
third of the lines to express the same things as in Java. That’s a
The major - and crucial - difference between current Ruby’s threads and
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.
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).
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.
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.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.