JRuby vs Ruby: why would you ever use ruby?

Why would anyone use ruby over Jruby? I'm admittedly a noob about all
this stuff, but from what I've read jruby seems superior to ruby and
quite a bit faster. What would be the disadvantages of JRuby? I man
it's possible to use it with rails now, and JRuby is what's used by
default in netbeans (which is the ide I think I've settled on). So
why not JRuby? Would the tutorials be all that different?

Why would anyone use ruby over Jruby? I’m admittedly a noob about all

this stuff, but from what I’ve read jruby seems superior to ruby and

quite a bit faster. What would be the disadvantages of JRuby? I man

it’s possible to use it with rails now, and JRuby is what’s used by

default in netbeans (which is the ide I think I’ve settled on). So

why not JRuby? Would the tutorials be all that different?

You’re pretty much free to use any implementation of Ruby for your project.

Also, it really come down to what are your underlying project requirements.

So, why would anyone use Ruby over JRuby?

o dictated by the company

o existing part of current IT infrastructure

o has support for many of the Ruby 3rd party libraries/frameworks/plugins

o developing Ruby C extensions

So, why would anyone use JRuby over Ruby?

o very good performing JVM and much faster than Ruby 1.8.6 (.i.e MRI) and is on par

with Ruby 1.9.1 (i.e YARV) in a lot of the tests that I have seen online

o allows me to access some very popular Java libraries from Ruby

o supports both Ruby 1.8.6 and Ruby 1.9 language specifications

o has very good support for Rails today

o has very good support for Google App Engine today

o can use a multitude of web server configurations both Java and non-Java

o has support for true multi-threading because the Global Interpreter Lock (GIL) doesn’t exist

I’m sure that there are many more pros for selecting Ruby over JRuby and vice-versa but you

should be able to get the picture. Please take a look at the following links for additional information:

http://www.infoq.com/interviews/charles-nutter-jruby

http://www.jruby.com

You might want to also ask your question on the following list which is dedicated

to the JRuby community:

http://groups.google.com/group/jruby-users

Good luck,

-Conrad

My two cents.
None of the RMagick stuff with attachment_fu would work when I tried
to use JRuby. They said they had something like JMagick? but nobody I
contacted seemed to use photos in their application???
David

AlwaysCharging wrote:

Why would anyone use ruby over Jruby? I'm admittedly a noob about all
this stuff, but from what I've read jruby seems superior to ruby and
quite a bit faster. What would be the disadvantages of JRuby?

It's Java. This is both an advantage and a disadvantage: you already
know about the advantages, but server-side Java can be hard to set up
for Web stuff. Personally, I'm using Ruby Enterprise Edition on many of
my servers, which gives better performance but without the hassle of
JRuby.

I man
it's possible to use it with rails now, and JRuby is what's used by
default in netbeans (which is the ide I think I've settled on).

That is a bad reason to pick JRuby. Anyway, you probably shouldn't be
using Netbeans: it's a good IDE, but not for Rails. It's stupid enough
not to pick up generators properly, and in my experience, it doesn't
integrate all that well with Rails anyway, although I may try it again
in a year or two.

Anyway, I would urge you (especially at first) not to use an IDE for
Rails. IDEs are great for heavy Java frameworks where there are lots of
config files to automatically generate, but I do not believe they are
necessary -- or even desirable -- for Rails. Use a good editor such as
KomodoEdit (my current choice), TextMate, or jEdit and a bunch of
terminal windows. If you use an IDE for Rails you'll actually be making
your life harder.

So
why not JRuby? Would the tutorials be all that different?

As far as the language is concerned, no. As far as Web server setup is
concerned, yes, very much.

Note: the server setup can actually be an advantage if you already have
a Java setup that you want to integrate with. I don't, so I'd rather
not deal with Java servlet containers.

Best,

My two cents.

None of the RMagick stuff with attachment_fu would work when I tried

to use JRuby. They said they had something like JMagick? but nobody I

contacted seemed to use photos in their application???

David

David, have you posted to the JRuby mailing list in regards to RMagick or

support for the Ruby C-Extensions? Also, you can find some additional

limitations with JRuby here:

http://jruby.codehaus.org/Limitations

-Conrad

FWIW, ImageMagick with the mini_magick gem works fine with JRuby
(using attachment_fu).

I would say native multi-threading is a huge plus for Jruby as well.

For image processing I believe image-vodoo has been had with much
success in the Jruby world (as well as attachment_fu and rmagick)

One negative for Jruby is if you want to use a gem with a native-C
only extension then you are out of luck, but most so far I have seen
have had C and Jave implementations of the gem.

AD

I would say native multi-threading is a huge plus for Jruby as well.

Why do you say this? Most request/response cycles are so quick that
they are unlikely to benefit significantly from multithreading. How
"huge" a win is multi-threading in the timespan of ... say ... < 30ms?

It's a HUGE win 'cos if you have a machine with multiple processing
cores (something that's as common as a keyboard and a mouse nowadays)
your server can benefit from them without a separate process and all
the monitoring/memory/OS footprint that this solution carries.

It's a huge win if you have blocking tasks. It's not if you have tasks that cannot be parallelized. My point is that a good deal of the stuff you do between when you get a request and when you serve a response is done in a linear manner. If you were going out and foraging among several Web services to create a composite response then fine, multithread away.

Multithreading is just peachy for systems where orthogonal bodies of work can be isolated into threads and run at their own pace and/or block on external dependencies like IO, to coalesce when possible. For example, finding and formatting a bunch of data and populating a listbox in a client app without freezing the UI. But such orthogonality is seldom, in my experience, found in that brief instant between a user request and the time the response must be issued.

So my question is still: How much of a practical (not theoretical) win is MT for a Web application and does the J in JRuby really increase the win over green threads for this brief a set of tasks?

Just asking...

Why do you say this? Most request/response cycles are so quick that

they are unlikely to benefit significantly from multithreading. How

“huge” a win is multi-threading in the timespan of … say … <

30ms?

It’s a HUGE win 'cos if you have a machine with multiple processing

cores (something that’s as common as a keyboard and a mouse nowadays)

your server can benefit from them without a separate process and all

the monitoring/memory/OS footprint that this solution carries.

It’s a huge win if you have blocking tasks. It’s not if you have tasks

that cannot be parallelized. My point is that a good deal of the stuff

you do between when you get a request and when you serve a response is

done in a linear manner. If you were going out and foraging among

several Web services to create a composite response then fine,

multithread away.

I can have long running tasks that does not block. I can stuff it in a thread,

return to the caller, and wait for a notification. This can be done using a

single thread and no additional plugins.

In C-Ruby, the way to work around the GIL to achieve concurrency is to

push this functionality down into the Ruby C-Extension. Thus, you’ll be

using processes for thread parallelism. This workaround isn’t needed with

JRuby. JRuby provides a threading model which allows one to write truly

concurrent Rails applications because it’s not limited by a GIL as

it is in C-Ruby (i.e. MRI/YARV). Also, JRuby uses system native threads

that operate concurrently instead of green threads.

Next, I have seen better resource utilization by using VMs that

support multiple cores. What’s the point of having an 8 core machine and

10 mongrels running on a single core?

Multithreading is just peachy for systems where orthogonal bodies of

work can be isolated into threads and run at their own pace and/or

block on external dependencies like IO, to coalesce when possible. For

example, finding and formatting a bunch of data and populating a

listbox in a client app without freezing the UI. But such

orthogonality is seldom, in my experience, found in that brief instant

between a user request and the time the response must be issued.

You should try writing a multi-threaded Rails application and see where it

takes you.

So my question is still: How much of a practical (not theoretical) win

is MT for a Web application and does the J in JRuby really increase

the win over green threads for this brief a set of tasks?

In short, JRuby opens the door to accessing the wealth of Java libraries

and frameworks. Also, it provides a truly current threading model using

system native threads and I’m glad that there are other implementations

leveraging the environments that are used to build them.

-Conrad

Conrad Taylor wrote:
[some very good stuff about threads]

You should try writing a multi-threaded Rails application and see where
it
takes you.

Surely this is putting the cart before the horse. Except for toy
proof-of-concept apps, if I wind up with a multithreaded Rails app, it
won't be because I set out to write a multithreaded Rails app. Rather,
it will be because I set out to implement some functionality, and that
functionality requires multiple threads.

[...]

In short, JRuby opens the door to accessing the wealth of Java libraries
and frameworks.

Thanks, but no thanks. If I wanted that, I'd just use Java. (There are
perhaps a couple of exceptions to that response, thoughm)

Also, it provides a truly current threading model using
system native threads and I'm glad that there are other implementations
leveraging the environments that are used to build them.

As am I. But like Steve, I'm not convinced that this means a heck of a
lot for many Rails apps. (For some, though, it will mean a lot, to be
sure.)

-Conrad

Best,

>
>>
>> Why do you say this? Most request/response cycles are so quick that
>> they are unlikely to benefit significantly from multithreading. How
>> "huge" a win is multi-threading in the timespan of ... say ... <
>> 30ms?
>>
>
> It's a HUGE win 'cos if you have a machine with multiple processing
> cores (something that's as common as a keyboard and a mouse nowadays)
> your server can benefit from them without a separate process and all
> the monitoring/memory/OS footprint that this solution carries.
>

It's a huge win if you have blocking tasks. It's not if you have tasks
that cannot be parallelized. My point is that a good deal of the stuff
you do between when you get a request and when you serve a response is
done in a linear manner. If you were going out and foraging among
several Web services to create a composite response then fine,
multithread away.

I can have long running tasks that does not block. I can stuff it in a thread,
return to the caller, and wait for a notification. This can be done using a
single thread and no additional plugins.

And the common everyday Rails applicability of being able to stuff a long-running task into a thread is what I've seldom seen.

In C-Ruby, the way to work around the GIL to achieve concurrency is to
push this functionality down into the Ruby C-Extension. Thus, you'll be
using processes for thread parallelism. This workaround isn't needed with
JRuby. JRuby provides a threading model which allows one to write truly
concurrent Rails applications because it's not limited by a GIL as
it is in C-Ruby (i.e. MRI/YARV). Also, JRuby uses system native threads
that operate concurrently instead of green threads.

I understand the difference between the OS-native threads and Ruby's threads that run under the GIL. Multi-processing is, however, not the worst solution. Consider this: There is no standard IPC for the threaded model because threads run (duh) in-process. So how do threads communicate? Shared (global?) variables. So now you are facing concurrency problems, setting and releasing mutexes, and all the other keen stuff you don't have to do if you use the more constrained multi-process model.

Next, I have seen better resource utilization by using VMs that
support multiple cores. What's the point of having an 8 core machine and
10 mongrels running on a single core?

That's like saying why have a car that can go 150 when the speed limit is 65? Having multiple cores is not a reason in and of itself to design multithreaded solutions. Some problems are well-suited to parallel solutions; some aren't. But the problem is not defined by the target architecture.

Multithreading is just peachy for systems where orthogonal bodies of
work can be isolated into threads and run at their own pace and/or
block on external dependencies like IO, to coalesce when possible. For
example, finding and formatting a bunch of data and populating a
listbox in a client app without freezing the UI. But such
orthogonality is seldom, in my experience, found in that brief instant
between a user request and the time the response must be issued.

You should try writing a multi-threaded Rails application and see where it
takes you.

I have. It takes me into a painstaking exercise in protecting myself against elusive and difficult to reproduce concurrency bugs.

So my question is still: How much of a practical (not theoretical) win
is MT for a Web application and does the J in JRuby really increase
the win over green threads for this brief a set of tasks?

In short, JRuby opens the door to accessing the wealth of Java libraries
and frameworks. Also, it provides a truly current threading model using
system native threads and I'm glad that there are other implementations
leveraging the environments that are used to build them.

I'm really not missing Java that much.

I think multi-threading is just another arrow in the quiver of the good software designer. Having been down this road many times, I find it difficult to characterize multi-threading as a "huge win" in the context of Web applications.

Why do you say this? Most request/response cycles are so quick that

they are unlikely to benefit significantly from multithreading. How

“huge” a win is multi-threading in the timespan of … say … <

30ms?

It’s a HUGE win 'cos if you have a machine with multiple processing

cores (something that’s as common as a keyboard and a mouse

nowadays)

your server can benefit from them without a separate process and all

the monitoring/memory/OS footprint that this solution carries.

It’s a huge win if you have blocking tasks. It’s not if you have tasks

that cannot be parallelized. My point is that a good deal of the stuff

you do between when you get a request and when you serve a response is

done in a linear manner. If you were going out and foraging among

several Web services to create a composite response then fine,

multithread away.

The things that happen between a request and response do not need to

be done in a linear manner. This is your choice and you may be constrained

to do this for many reasons. Also, you might have a well defined workflow

which dictates when, where, and how information is to be processed.

I can have long running tasks that does not block. I can stuff it

in a thread,

return to the caller, and wait for a notification. This can be done

using a

single thread and no additional plugins.

And the common everyday Rails applicability of being able to stuff a

long-running task into a thread is what I’ve seldom seen.

Yes, this is true of the common everyday application. However, others

are doing innovative and difference things with the Ruby language in

addition to Rails.

In C-Ruby, the way to work around the GIL to achieve concurrency is to

push this functionality down into the Ruby C-Extension. Thus,

you’ll be

using processes for thread parallelism. This workaround isn’t

needed with

JRuby. JRuby provides a threading model which allows one to write

truly

concurrent Rails applications because it’s not limited by a GIL as

it is in C-Ruby (i.e. MRI/YARV). Also, JRuby uses system native

threads

that operate concurrently instead of green threads.

I understand the difference between the OS-native threads and Ruby’s

threads that run under the GIL. Multi-processing is, however, not the

worst solution. Consider this: There is no standard IPC for the

threaded model because threads run (duh) in-process. So how do threads

communicate? Shared (global?) variables. So now you are facing

concurrency problems, setting and releasing mutexes, and all the other

keen stuff you don’t have to do if you use the more constrained multi-

process model.

I can safely safe after playing with Grand Central Dispatch for 2.5 months,

it’s the way to go for doing MT which alleviates most of the problems that

you mention above.

Next, I have seen better resource utilization by using VMs that

support multiple cores. What’s the point of having an 8 core

machine and

10 mongrels running on a single core?

That’s like saying why have a car that can go 150 when the speed limit

is 65? Having multiple cores is not a reason in and of itself to

design multithreaded solutions. Some problems are well-suited to

parallel solutions; some aren’t. But the problem is not defined by the

target architecture.

I’m simply sayint that one shouldn’t waste resources. Yes, I agree with you

that having multiple cores isn’t the reason for MT but having the ability

to distribute load across cores is better than wasting cores or buying

additional hardware that’s not needed. Yes, the problem isn’t defined by the target

architecture but the solution is defined by the target architecture. This

is very consistent within software development in understanding your

risk analysis in the design phase of your project.

Multithreading is just peachy for systems where orthogonal bodies of

work can be isolated into threads and run at their own pace and/or

block on external dependencies like IO, to coalesce when possible. For

example, finding and formatting a bunch of data and populating a

listbox in a client app without freezing the UI. But such

orthogonality is seldom, in my experience, found in that brief instant

between a user request and the time the response must be issued.

You should try writing a multi-threaded Rails application and see

where it

takes you.

I have. It takes me into a painstaking exercise in protecting myself

against elusive and difficult to reproduce concurrency bugs.

So my question is still: How much of a practical (not theoretical) win

is MT for a Web application and does the J in JRuby really increase

the win over green threads for this brief a set of tasks?

In short, JRuby opens the door to accessing the wealth of Java

libraries

and frameworks. Also, it provides a truly current threading model

using

system native threads and I’m glad that there are other

implementations

leveraging the environments that are used to build them.

I’m really not missing Java that much.

I’m not a huge fan of Java but JRuby is simply another option within

the Ruby landscape. You can take it or leave it.

I think multi-threading is just another arrow in the quiver of the

good software designer. Having been down this road many times, I find

it difficult to characterize multi-threading as a “huge win” in the

context of Web applications.

MT is generally a hard topic but GCD is making it very easy these days.

-Conrad

GCD is incredibly exciting. Yes, this really got me going too. But it's of so much more direct value to Cocoa apps than Web apps -- unless you intend to deploy on a Mac SL Server. If GCD lives up to its potential, things like Photoshop and Lightroom might get downright snappy. But unless it can be backported to Linux, the general applicability for most Web deployments is questionable.

I *am* a fan of parallel processing. Works like a charm for certain tasks where the load can be effectively distributed and that includes pretty much every client app that needs to keep a UI active and responsive while drawing stuff on the screen or interacting with persistent data. Web apps... well, Apache has the MPM model that distributes across any cores that are available, and many use load-balancing proxies to run a pack of mongrels. Mongrel itself can distribute some of its processing, as some of it is native.

We'll see if MT makes a big impact on Rails development as a result of the Snow Leopard release.

except that each mongrel is a separate process and so they will get
spread across multiple cores (not to say that ruby 1.8's threading
don't suck and of course you'll save memory by having 1 ten threaded
instance rather than 10 1 threaded instances).

Fred

If you want to use attachment_fu, you can look at image_voodoo, a
JRuby version of image_science...I think that gives you everything you
need.

The RMagick-lookalike project is rmagick4j. It has enough implemented
to pass all of Gruff Graph's tests, which is pretty good. But it's not
100%.

- Charlie

It's Java. This is both an advantage and a disadvantage: you already
know about the advantages, but server-side Java can be hard to set up
for Web stuff. Personally, I'm using Ruby Enterprise Edition on many of
my servers, which gives better performance but without the hassle of
JRuby.

JRuby works fine as a Mongrel process (and if you turn on threadsafe
mode in Rails, your entire site can be a *single* process). There's
also the glassfish gem, which allows one-command deployment of an
entire app, all in a single process. I think the difficulty of setting
up JRuby on the server has been vastly overstated.

$ gem install glassfish
$ glassfish -e production <appdir>

That's it.

http://blog.headius.com/2009/04/apache-jruby-rails-glassfish-easy.html

> I man
> it's possible to use it with rails now, and JRuby is what's used by
> default in netbeans (which is the ide I think I've settled on).

That is a bad reason to pick JRuby. Anyway, you probably shouldn't be
using Netbeans: it's a good IDE, but not for Rails. It's stupid enough
not to pick up generators properly, and in my experience, it doesn't
integrate all that well with Rails anyway, although I may try it again
in a year or two.

There's actually a number of people that like NetBeans (or one of the
other IDEs) a lot for Rails work. And of course if you're working with
several languages, it does a very good job.

Anyway, I would urge you (especially at first) not to use an IDE for
Rails. IDEs are great for heavy Java frameworks where there are lots of
config files to automatically generate, but I do not believe they are
necessary -- or even desirable -- for Rails. Use a good editor such as
KomodoEdit (my current choice), TextMate, or jEdit and a bunch of
terminal windows. If you use an IDE for Rails you'll actually be making
your life harder.

I don't think that's true. But it's a matter of opinion. Even if you
don't use those IDEs as anything more than editors, they're very nice
editors.

As far as the language is concerned, no. As far as Web server setup is
concerned, yes, very much.

Note: the server setup can actually be an advantage if you already have
a Java setup that you want to integrate with. I don't, so I'd rather
not deal with Java servlet containers.

You don't have to deploy to a Java servlet container, and for typical
Rubyists we actually recommend using one of the non-servlet options.

- Charlie

I'll go a little bit controversial now: the fact that typical Rails
deployments have to spin up multiple processes is totally mickey-
mouse. What decade is this?

With JRuby, just by avoiding the use of globally-accessible variables
(globals, class variables) you can run an entire site with a single
Rails instance in a single process. We've had reports from people
running on 16-core boxes with JRuby in a single 100-200MB process,
handling *thousands* of end-to-end requests per second. How many
Mongrels or REE processes would you need to do that? At least 16 to
make use of all the cores, and more if you don't want cores to sit
idle half the time while blocking on IO.

Multithreading in JRuby doesn't mean you need to write multi-threaded
Rails apps; it means you get to take advantage of Rails thread-safe
mode (2.2+) to shove as many requests as you possibly can through a
single instance. No other Ruby implementation can do that.

- Charlie

What prevents this from working properly in Ruby 1.9?