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