Rails - Aug 2009 - 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?

On Sat, Aug 15, 2009 at 10:45 PM, AlwaysCharging
<goodgets-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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?  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

>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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

On Aug 16, 3:35 am, Conrad Taylor
<conra...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On Sat, Aug 15, 2009 at 10:45 PM, AlwaysCharging
<goodg...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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?  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-jrubyhttp://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
>
>
>
> - Hide quoted text -
>
> - Show quoted text -

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,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

On Sun, Aug 16, 2009 at 7:29 AM, InventoryTrackers <
inventorytrackers-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> 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

>
> On Aug 16, 3:35 am, Conrad Taylor
<conra...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Sat, Aug 15, 2009 at 10:45 PM, AlwaysCharging
<goodg...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 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?  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-jrubyhttp://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
> >
> >
> >
> > - Hide quoted text -
> >
> > - Show quoted text -
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Sun, Aug 16, 2009 at 7:29 AM,
InventoryTrackers<inventorytrackers-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> 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???
FWIW, ImageMagick with the mini_magick gem works fine with JRuby
(using attachment_fu).

-- 
Hassan Schroeder ------------------------
hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
twitter: @hassan

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

On Sun, Aug 16, 2009 at 10:57 AM, Hassan
Schroeder<hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> On Sun, Aug 16, 2009 at 7:29 AM,
>
InventoryTrackers<inventorytrackers-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>>
>> 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???
>
> FWIW, ImageMagick with the mini_magick gem works fine with JRuby
> (using attachment_fu).
>
> --
> Hassan Schroeder ------------------------
hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> twitter: @hassan
>
> >
>

Marnen Laibow-Koser wrote:
> 
> 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.
C''mon Marnen,

Don''t bash netbeans, especially 6.7.  The differences from 6.5 to 6.7 
are large.  Since moving to 6.7, I have had very limited issues with 
netbeans and rails.  I made several other attempts at other IDEs and 
even going with simple text editors.  I came back to netbeans when 6.7 
was released and have not looked back.

Also, I do not use JRuby so I agree with you on the fact that an IDE 
shouldn''t determine which ruby version you use.  NB supports multiple 
platforms in multiple locations.  You can remove JRuby from the list of 
available platforms if you want to do so as well.

-- 
Posted via http://www.ruby-forum.com/.

Alpha Blue wrote:
[...]
> C''mon Marnen,
> 
> Don''t bash netbeans,
Why not?  It doesn''t work well with Rails.  I do not recommend it for 
Rails work, and I make no apologies for that fact.
> especially 6.7.  The differences from 6.5 to 6.7 
> are large.
I believe my only experience with NetBeans was with 6.7, but I will make 
sure of that.  If I was in fact using 6.5, I will be happy to try 6.7.

>  Since moving to 6.7, I have had very limited issues with 
> netbeans and rails. 
Me too.  But I don''t want "very limited issues".  I want no
avoidable
issues.  I use and recommend a set of tools that achieves that goal. 
NetBeans is not one of those tools.
> I made several other attempts at other IDEs and 
> even going with simple text editors.  I came back to netbeans when 6.7 
> was released and have not looked back.
Perhaps you''re using a different subset of Rails features than I am,
and
NetBeans happens to support what you need (though even so, I still do 
not believe that most IDEs are appropriate for Rails).
> 
> Also, I do not use JRuby so I agree with you on the fact that an IDE 
> shouldn''t determine which ruby version you use. 
That''s a bad reason to agree with me. :)
> NB supports multiple 
> platforms in multiple locations.  You can remove JRuby from the list of 
> available platforms if you want to do so as well.
Yup.

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

On Aug 16, 2009, at 4:18 PM,
straightflush-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
>
> 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?
> 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
>
> On Sun, Aug 16, 2009 at 10:57 AM, Hassan
> Schroeder<hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>>
>> On Sun, Aug 16, 2009 at 7:29 AM,
>>
InventoryTrackers<inventorytrackers-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>>>
>>> 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???
>>
>> FWIW, ImageMagick with the mini_magick gem works fine with JRuby
>> (using attachment_fu).
>>
>> --
>> Hassan Schroeder ------------------------
hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>> twitter: @hassan
>>
>>>
>>
>
> >

On Sun, Aug 16, 2009 at 10:47 PM,
s.ross<cwdinfo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> 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.

-
Maurício Linhares
http://codeshooter.wordpress.com/ | http://twitter.com/mauriciojr

On Aug 16, 2009, at 6:51 PM, Maurício Linhares wrote:
>
> On Sun, Aug 16, 2009 at 10:47 PM,
s.ross<cwdinfo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> 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...

On Sun, Aug 16, 2009 at 7:07 PM, s.ross
<cwdinfo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
> On Aug 16, 2009, at 6:51 PM, Maurício Linhares wrote:
>
> >
> > On Sun, Aug 16, 2009 at 10:47 PM,
s.ross<cwdinfo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>
> >> 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

>
>
> Just asking...
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

On Aug 16, 2009, at 9:40 PM, Conrad Taylor wrote:
> On Sun, Aug 16, 2009 at 7:07 PM, s.ross
<cwdinfo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
> On Aug 16, 2009, at 6:51 PM, Maurício Linhares wrote:
>
> >
> > On Sun, Aug 16, 2009 at 10:47 PM,
s.ross<cwdinfo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>
> >> 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.

On Sun, Aug 16, 2009 at 10:36 PM, s.ross
<cwdinfo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
> On Aug 16, 2009, at 9:40 PM, Conrad Taylor wrote:
>
> > On Sun, Aug 16, 2009 at 7:07 PM, s.ross
<cwdinfo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >
> > On Aug 16, 2009, at 6:51 PM, Maurício Linhares wrote:
> >
> > >
> > > On Sun, Aug 16, 2009 at 10:47 PM,
s.ross<cwdinfo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > >>
> > >> 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

>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Aug 16, 2009, at 11:53 PM, Conrad Taylor wrote:
> 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. [concurrency bugs, deadlocks, race conditions,  
> etc., -- steve]
>
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.

On Aug 17, 5:40 am, Conrad Taylor
<conra...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> 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?
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

On Aug 16, 7:29 am, InventoryTrackers
<inventorytrack...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 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???
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

On Aug 16, 7:55 am, Marnen Laibow-Koser <rails-mailing-l...@andreas-
s.net> wrote:
> 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

On Aug 16, 10:36 pm, "s.ross"
<cwdi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 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.
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

On Aug 18, 3:59 pm, Charles Oliver Nutter
<head...-miBPJv7AA1lBDgjK7y7TUQ@public.gmane.org> wrote:
> 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?

Charles Nutter wrote:
[...]
> JRuby works fine as a Mongrel process (and if you turn on threadsafe
> mode in Rails, your entire site can be a *single* process).
I''m using Passenger right now, not Mongrel, but I''ll keep that
in mind.
> 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.
That may be worth trying out, then.  I don''t think that was available 
the last time I looked at JRuby seriously.

[...]
> There''s actually a number of people that like NetBeans (or one of
the
> other IDEs) a lot for Rails work. 
I''m well aware of that.  I''m not one of them.
> And of course if you''re working with
> several languages, it does a very good job.
If I were doing a multilanguage project, of course I''d try to find an 
IDE that handled them all well.  However, I''m not, which means I get to
pick an IDE that is best for what I''m working with.  That currently 
means no IDE as such for Rails, and probably (speaking hypothetically) 
Xcode for Objective-C, Eclipse or perhaps NetBeans for Java...
[...]
>  Even if you
> don''t use those IDEs as anything more than editors,
they''re very nice
> editors.
No they''re not; in fact, Eclipse and NetBeans both kind of suck as 
editors.  KomodoEdit blows them both out of the water, and I understand 
TextMate blows KomodoEdit out of the water.  No word-wrap in Eclipse or 
NetBeans?  Srsly?  What decade is this? :)

[...]
> 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.
Good to know.  I will be the first to admit that I''m no Java expert, so
this is very helpful.
> 
> - Charlie
Thanks for the advice on JRuby straight from the horse''s mouth!


Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

On Aug 18, 3:58 pm, pharrington
<xenogene...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On Aug 18, 3:59 pm, Charles Oliver Nutter
<head...-miBPJv7AA1lBDgjK7y7TUQ@public.gmane.org> wrote:
>
> > 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.
>
> What prevents this from working properly in Ruby 1.9?
Ruby 1.9 has a "giant lock" that prevents threads from running in
parallel. So even though they''re native, you''d still need 16
processes
to utilize 16 cores fully. The only implementations to support actual
parallel-executing threads are JRuby, IronRuby, and MacRuby. Of these,
only IronRuby and JRuby run Rails. Of these, only JRuby is production-
ready and fast.

Ruby 1.9 *may* also suffer from issues common to other GIL-based
systems like Python (giant interpreter lock), since you start to have
the OS scheduler and the GIL scheduler fighting each other. Here''s a
good presentation on the issues in Python:

http://blip.tv/file/2232410/

- Charlie

On Aug 18, 5:32 pm, Charles Oliver Nutter
<head...-miBPJv7AA1lBDgjK7y7TUQ@public.gmane.org>
wrote:
> On Aug 18, 3:58 pm, pharrington
<xenogene...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > On Aug 18, 3:59 pm, Charles Oliver Nutter
<head...-miBPJv7AA1lBDgjK7y7TUQ@public.gmane.org> wrote:
>
> > > 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.
>
> > What prevents this from working properly in Ruby 1.9?
>
> Ruby 1.9 has a "giant lock" that prevents threads from running in
> parallel. So even though they''re native, you''d still need
16 processes
> to utilize 16 cores fully. The only implementations to support actual
> parallel-executing threads are JRuby, IronRuby, and MacRuby. Of these,
> only IronRuby and JRuby run Rails. Of these, only JRuby is production-
> ready and fast.
>
> Ruby 1.9 *may* also suffer from issues common to other GIL-based
> systems like Python (giant interpreter lock), since you start to have
> the OS scheduler and the GIL scheduler fighting each other. Here''s
a
> good presentation on the issues in Python:
>
> http://blip.tv/file/2232410/
>
> - Charlie
Makes sense, not sure why I didn''t remember that (especially when I
directly ran into this with a somewhat toyish app that does alot of
CPU intensive work in threaded batches). Thanks.

At 10:45 PM -0700 8/15/09, 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?  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?
I use both MRI and JRuby -- often at the same time in the same 
project when developing.

One advantage I didn''t see in the thread so for MRI is that the 
interpreter starts fast. This is great when starting lots of small 
tasks from the console.

Here''s a couple of pluses for JRuby that I haven''t seen
mentioned:

1) It is very easy to make multiple, complete, and isolated Ruby 
installation using JRuby. I know there are some tools to make this 
easier in MRI -- I even wrote a simple one -- but this is trivial in 
JRuby.

2) For some rendering operations in development mode JRuby can be 20x faster.

This is a strange result -- in general I''ve found JRuby to be about 
twice as fast as MRI in production ... but I''d never seen this result 
before ...

I''ve got a complex Rails application for authoring secondary science 
investigations and one of the render tasks generates a composite xml 
document that represents all of the objects in an investigation. 
Right now the largest investigation is about 350k rendered into xml 
and represents over 1100 objects. Roughly that corresponds to about 
1100 partial calls.

I have not done ANY work on improving performance in the rendering 
speed yet (lots of partials calling partials) and noticed that the 
render speed when running in MRI in development mode has gotten very 
long as authors have finally started making real investigations.

I put together a benchmark measuring the time to render 11 
investigations in xml.

The JRuby results were quite impressive:

           Development   Production
======================================MRI:        849s           30s
JRuby:       35s           18s

The rendering is done with HAML.

I have no idea why rendering in dev mode in MRI is SO slow.

There''s obviously a problem somewhere in the interaction with Rails, 
my code, MRI and development mode. But the fact that JRuby running in 
development mode renders all 11 Investigations into xml only 15% 
slower than MRI in production is great.  It also means that when I am 
testing or developing these features in the app I run my dev server 
in JRuby.

While I plan to work on performance later in most cases in production 
the Investigations will be frozen and the xml doc will be served from 
a page cache -- so performance improvements in rendering are not on 
the critical path for the production app.

This is running on Mac OS X 10.5.8 and Rails 2.3.3

MRI and JRuby versions:

$ jruby -v
jruby 1.4.0dev (ruby 1.8.7p174) (2009-08-09 6586) (Java HotSpot(TM)
Client VM 1.5.0_19) [i386-java]

$ ruby -v
ruby 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0]

more details:

http://groups.google.com/group/cc-developers/browse_thread/thread/af4ca01be8eb41ab?hl=en

Sorry, I still can''t understand how to run rails in thread safe mode 
under JRuby (one running instance supporting multiple concurrent requests).

If I try to enable config.threadsafe! in 
config/environments/production.rb under Glassfish Gem my Rails 
application still run single threaded.

Here a very simple example (environment is: glassfish gem v. 0.9.5 / 
jruby 1.3.1 / rails 2.3.3 / ubuntu 9.04 / notebook centrino dual core / 
2gb Ram):

rails concurrent
cd concurrent
script/generate controller test test

edit app/controllers/test_controller.rb, modify source as follow:

class TestController < ApplicationController
  def test
    @value = Time.now
    sleep 10
  end
end

edit app/views/test/test.html.erb, modify source as follow:

<%= @value %>

edit config/environments/production.rb, uncomment last line as follow:

config.threadsafe!

edit config/environemt.rbm uncomment frameworks line as follow (no 
database, resource, mail support for this very simple
test...):

config.frameworks -= [ :active_record, :active_resource, :action_mailer ]

Now run:

jruby -S gfrake config

edit config/glassfish.yml, modify config as follow (notice 4 runtime 
instances !):

environment: production
jruby-runtime-pool:
initial: 4
min: 4
max: 4

And finally start glassfish gem:

jruby -S glassfish

Now, if you try to call 4 times (concurrently) the following url...

http://localhost:3000/test/test

...you must wait 40 seconds for the 4th response...

This is a wrong behaviour because trying the same test under phusion 
passenger I wait only 10 seconds for the 4th response
(in fact passenger start up 4 rails processes, 1 for each concurrent 
request)...

I want to know if is it possible to run Rails with only one running 
instance supporting multiple concurrent requests...

Many thanks in advance...
> At 10:45 PM -0700 8/15/09, 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?  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?
>>     
>
> I use both MRI and JRuby -- often at the same time in the same 
> project when developing.
>
> One advantage I didn''t see in the thread so for MRI is that the 
> interpreter starts fast. This is great when starting lots of small 
> tasks from the console.
>
> Here''s a couple of pluses for JRuby that I haven''t seen
mentioned:
>
> 1) It is very easy to make multiple, complete, and isolated Ruby 
> installation using JRuby. I know there are some tools to make this 
> easier in MRI -- I even wrote a simple one -- but this is trivial in 
> JRuby.
>
> 2) For some rendering operations in development mode JRuby can be 20x
faster.
>
> This is a strange result -- in general I''ve found JRuby to be
about
> twice as fast as MRI in production ... but I''d never seen this
result
> before ...
>
> I''ve got a complex Rails application for authoring secondary
science
> investigations and one of the render tasks generates a composite xml 
> document that represents all of the objects in an investigation. 
> Right now the largest investigation is about 350k rendered into xml 
> and represents over 1100 objects. Roughly that corresponds to about 
> 1100 partial calls.
>
> I have not done ANY work on improving performance in the rendering 
> speed yet (lots of partials calling partials) and noticed that the 
> render speed when running in MRI in development mode has gotten very 
> long as authors have finally started making real investigations.
>
> I put together a benchmark measuring the time to render 11 
> investigations in xml.
>
> The JRuby results were quite impressive:
>
>            Development   Production
> ======================================> MRI:        849s           30s
> JRuby:       35s           18s
>
> The rendering is done with HAML.
>
> I have no idea why rendering in dev mode in MRI is SO slow.
>
> There''s obviously a problem somewhere in the interaction with
Rails,
> my code, MRI and development mode. But the fact that JRuby running in 
> development mode renders all 11 Investigations into xml only 15% 
> slower than MRI in production is great.  It also means that when I am 
> testing or developing these features in the app I run my dev server 
> in JRuby.
>
> While I plan to work on performance later in most cases in production 
> the Investigations will be frozen and the xml doc will be served from 
> a page cache -- so performance improvements in rendering are not on 
> the critical path for the production app.
>
> This is running on Mac OS X 10.5.8 and Rails 2.3.3
>
> MRI and JRuby versions:
>
> $ jruby -v
> jruby 1.4.0dev (ruby 1.8.7p174) (2009-08-09 6586) (Java HotSpot(TM)
> Client VM 1.5.0_19) [i386-java]
>
> $ ruby -v
> ruby 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0]
>
> more details:
>
>
http://groups.google.com/group/cc-developers/browse_thread/thread/af4ca01be8eb41ab?hl=en
>
> >
>
>   

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I believe for Jruby the min and max runtimes need to bet set to 1 for
this to happen and work with config.threadsafe!

AD

On Thu, Aug 27, 2009 at 9:18 AM, Gianluca
Tessarolo<tessarolo.gianluca-6ZZdBs7hMehZp5Udy/Obhg@public.gmane.org>
wrote:
> Sorry, I still can''t understand how to run rails in thread safe
mode under
> JRuby (one running instance supporting multiple concurrent requests).
>
> If I try to enable config.threadsafe! in config/environments/production.rb
> under Glassfish Gem my Rails application still run single threaded.
>
> Here a very simple example (environment is: glassfish gem v. 0.9.5 / jruby
> 1.3.1 / rails 2.3.3 / ubuntu 9.04 / notebook centrino dual core / 2gb Ram):
>
> rails concurrent
> cd concurrent
> script/generate controller test test
>
> edit app/controllers/test_controller.rb, modify source as follow:
>
> class TestController < ApplicationController
>   def test
>     @value = Time.now
>     sleep 10
>   end
> end
>
> edit app/views/test/test.html.erb, modify source as follow:
>
> <%= @value %>
>
> edit config/environments/production.rb, uncomment last line as follow:
>
> config.threadsafe!
>
> edit config/environemt.rbm uncomment frameworks line as follow (no
database,
> resource, mail support for this very simple
> test...):
>
> config.frameworks -= [ :active_record, :active_resource, :action_mailer ]
>
> Now run:
>
> jruby -S gfrake config
>
> edit config/glassfish.yml, modify config as follow (notice 4 runtime
> instances !):
>
> environment: production
> jruby-runtime-pool:
> initial: 4
> min: 4
> max: 4
>
> And finally start glassfish gem:
>
> jruby -S glassfish
>
> Now, if you try to call 4 times (concurrently) the following url...
>
> http://localhost:3000/test/test
>
> ...you must wait 40 seconds for the 4th response...
>
> This is a wrong behaviour because trying the same test under phusion
> passenger I wait only 10 seconds for the 4th response
> (in fact passenger start up 4 rails processes, 1 for each concurrent
> request)...
>
> I want to know if is it possible to run Rails with only one running
instance
> supporting multiple concurrent requests...
>
> Many thanks in advance...
>
> At 10:45 PM -0700 8/15/09, 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?  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?
>
>
> I use both MRI and JRuby -- often at the same time in the same
> project when developing.
>
> One advantage I didn''t see in the thread so for MRI is that the
> interpreter starts fast. This is great when starting lots of small
> tasks from the console.
>
> Here''s a couple of pluses for JRuby that I haven''t seen
mentioned:
>
> 1) It is very easy to make multiple, complete, and isolated Ruby
> installation using JRuby. I know there are some tools to make this
> easier in MRI -- I even wrote a simple one -- but this is trivial in
> JRuby.
>
> 2) For some rendering operations in development mode JRuby can be 20x
> faster.
>
> This is a strange result -- in general I''ve found JRuby to be
about
> twice as fast as MRI in production ... but I''d never seen this
result
> before ...
>
> I''ve got a complex Rails application for authoring secondary
science
> investigations and one of the render tasks generates a composite xml
> document that represents all of the objects in an investigation.
> Right now the largest investigation is about 350k rendered into xml
> and represents over 1100 objects. Roughly that corresponds to about
> 1100 partial calls.
>
> I have not done ANY work on improving performance in the rendering
> speed yet (lots of partials calling partials) and noticed that the
> render speed when running in MRI in development mode has gotten very
> long as authors have finally started making real investigations.
>
> I put together a benchmark measuring the time to render 11
> investigations in xml.
>
> The JRuby results were quite impressive:
>
>            Development   Production
> ======================================> MRI:        849s           30s
> JRuby:       35s           18s
>
> The rendering is done with HAML.
>
> I have no idea why rendering in dev mode in MRI is SO slow.
>
> There''s obviously a problem somewhere in the interaction with
Rails,
> my code, MRI and development mode. But the fact that JRuby running in
> development mode renders all 11 Investigations into xml only 15%
> slower than MRI in production is great.  It also means that when I am
> testing or developing these features in the app I run my dev server
> in JRuby.
>
> While I plan to work on performance later in most cases in production
> the Investigations will be frozen and the xml doc will be served from
> a page cache -- so performance improvements in rendering are not on
> the critical path for the production app.
>
> This is running on Mac OS X 10.5.8 and Rails 2.3.3
>
> MRI and JRuby versions:
>
> $ jruby -v
> jruby 1.4.0dev (ruby 1.8.7p174) (2009-08-09 6586) (Java HotSpot(TM)
> Client VM 1.5.0_19) [i386-java]
>
> $ ruby -v
> ruby 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0]
>
> more details:
>
>
http://groups.google.com/group/cc-developers/browse_thread/thread/af4ca01be8eb41ab?hl=en
>
>
>
>
>
> >
>

Many thanks for the suggestion, but the problem is still here...

My runtime configuration now is:

tex@tex-laptop:~xxx$ jruby -S glassfish
Parsing config file: /home/tex/xxx/config/glassfish.yml
Arguments:
    runtimes=>1
    runtimes_min=>1
    runtimes_max=>1
    contextroot=>/
    environment=>production
    app_dir=>/home/tex/xxx
    port=>3000
    pid=>
    log=>/home/tex/xxx/log/production.log
    log_console=>false
    log_level=>7
    daemon=>false
    jvm_options=>
    domain_dir=>/home/tex/xxx/tmp/.glassfish
Starting GlassFish server at: 127.0.0.1:3000 in production environment...
Writing log messages to: /home/tex/xxx/log/production.log.
Press Ctrl+C to stop.

The problem is always the same: 40 seconds for the 4th response...

I think I''m the only one on the heart that cannot run rails with JRuby 
with multiple concurrent requests, all the other out there seems that 
can run it without any problem (maybe I''m unlucky, sigh...)
> I believe for Jruby the min and max runtimes need to bet set to 1 for
> this to happen and work with config.threadsafe!
>
> AD
>
> On Thu, Aug 27, 2009 at 9:18 AM, Gianluca
> Tessarolo<tessarolo.gianluca-6ZZdBs7hMehZp5Udy/Obhg@public.gmane.org>
wrote:
>   
>> Sorry, I still can''t understand how to run rails in thread
safe mode under
>> JRuby (one running instance supporting multiple concurrent requests).
>>
>> If I try to enable config.threadsafe! in
config/environments/production.rb
>> under Glassfish Gem my Rails application still run single threaded.
>>
>> Here a very simple example (environment is: glassfish gem v. 0.9.5 /
jruby
>> 1.3.1 / rails 2.3.3 / ubuntu 9.04 / notebook centrino dual core / 2gb
Ram):
>>
>> rails concurrent
>> cd concurrent
>> script/generate controller test test
>>
>> edit app/controllers/test_controller.rb, modify source as follow:
>>
>> class TestController < ApplicationController
>>   def test
>>     @value = Time.now
>>     sleep 10
>>   end
>> end
>>
>> edit app/views/test/test.html.erb, modify source as follow:
>>
>> <%= @value %>
>>
>> edit config/environments/production.rb, uncomment last line as follow:
>>
>> config.threadsafe!
>>
>> edit config/environemt.rbm uncomment frameworks line as follow (no
database,
>> resource, mail support for this very simple
>> test...):
>>
>> config.frameworks -= [ :active_record, :active_resource, :action_mailer
]
>>
>> Now run:
>>
>> jruby -S gfrake config
>>
>> edit config/glassfish.yml, modify config as follow (notice 4 runtime
>> instances !):
>>
>> environment: production
>> jruby-runtime-pool:
>> initial: 4
>> min: 4
>> max: 4
>>
>> And finally start glassfish gem:
>>
>> jruby -S glassfish
>>
>> Now, if you try to call 4 times (concurrently) the following url...
>>
>> http://localhost:3000/test/test
>>
>> ...you must wait 40 seconds for the 4th response...
>>
>> This is a wrong behaviour because trying the same test under phusion
>> passenger I wait only 10 seconds for the 4th response
>> (in fact passenger start up 4 rails processes, 1 for each concurrent
>> request)...
>>
>> I want to know if is it possible to run Rails with only one running
instance
>> supporting multiple concurrent requests...
>>
>> Many thanks in advance...
>>
>> At 10:45 PM -0700 8/15/09, 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?  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?
>>
>>
>> I use both MRI and JRuby -- often at the same time in the same
>> project when developing.
>>
>> One advantage I didn''t see in the thread so for MRI is that
the
>> interpreter starts fast. This is great when starting lots of small
>> tasks from the console.
>>
>> Here''s a couple of pluses for JRuby that I haven''t
seen mentioned:
>>
>> 1) It is very easy to make multiple, complete, and isolated Ruby
>> installation using JRuby. I know there are some tools to make this
>> easier in MRI -- I even wrote a simple one -- but this is trivial in
>> JRuby.
>>
>> 2) For some rendering operations in development mode JRuby can be 20x
>> faster.
>>
>> This is a strange result -- in general I''ve found JRuby to be
about
>> twice as fast as MRI in production ... but I''d never seen this
result
>> before ...
>>
>> I''ve got a complex Rails application for authoring secondary
science
>> investigations and one of the render tasks generates a composite xml
>> document that represents all of the objects in an investigation.
>> Right now the largest investigation is about 350k rendered into xml
>> and represents over 1100 objects. Roughly that corresponds to about
>> 1100 partial calls.
>>
>> I have not done ANY work on improving performance in the rendering
>> speed yet (lots of partials calling partials) and noticed that the
>> render speed when running in MRI in development mode has gotten very
>> long as authors have finally started making real investigations.
>>
>> I put together a benchmark measuring the time to render 11
>> investigations in xml.
>>
>> The JRuby results were quite impressive:
>>
>>            Development   Production
>> ======================================>> MRI:        849s        
30s
>> JRuby:       35s           18s
>>
>> The rendering is done with HAML.
>>
>> I have no idea why rendering in dev mode in MRI is SO slow.
>>
>> There''s obviously a problem somewhere in the interaction with
Rails,
>> my code, MRI and development mode. But the fact that JRuby running in
>> development mode renders all 11 Investigations into xml only 15%
>> slower than MRI in production is great.  It also means that when I am
>> testing or developing these features in the app I run my dev server
>> in JRuby.
>>
>> While I plan to work on performance later in most cases in production
>> the Investigations will be frozen and the xml doc will be served from
>> a page cache -- so performance improvements in rendering are not on
>> the critical path for the production app.
>>
>> This is running on Mac OS X 10.5.8 and Rails 2.3.3
>>
>> MRI and JRuby versions:
>>
>> $ jruby -v
>> jruby 1.4.0dev (ruby 1.8.7p174) (2009-08-09 6586) (Java HotSpot(TM)
>> Client VM 1.5.0_19) [i386-java]
>>
>> $ ruby -v
>> ruby 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0]
>>
>> more details:
>>
>>
http://groups.google.com/group/cc-developers/browse_thread/thread/af4ca01be8eb41ab?hl=en
>>
>>
>>
>>
>>
>>     
>
> >
>
>   

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Aug 27, 8:18 am, Gianluca Tessarolo
<tessarolo.gianl...-6ZZdBs7hMehZp5Udy/Obhg@public.gmane.org>
wrote:
> Sorry, I still can''t understand how to run rails in thread safe
mode
> under JRuby (one running instance supporting multiple concurrent requests).
>
> If I try to enable config.threadsafe! in
> config/environments/production.rb under Glassfish Gem my Rails
> application still run single threaded.
> edit config/glassfish.yml, modify config as follow (notice 4 runtime
> instances !):
>
> environment: production
> jruby-runtime-pool:
> initial: 4
> min: 4
> max: 4
I think this is your mistake. You told Rails to run in threadsafe
mode, which Glassfish gem will pick up; but then you forced Glassfish
to run with a runtime pool of 4 instances. If you *don''t* do this it
works fine, and your four concurrent requests all take the same amount
of time (10s) to run because they''re running in parallel.

The only bottleneck you might run into with this contrived example is
that GF by default only has a certain size thread pool, and will start
to park requests until one of the request-processing threads is
available, but you can crank that up too if needed.

I assure you, Rails on JRuby runs great in threadsafe mode, with only
a single runtime. You can crank thousands of requests through a single
instance, something impossible to do with any other Ruby
implementation so far.

- Charlie

Dear All,

I think Ruby and JRuby both have their advantages.  It depends on the 
environment which one is easier to integrate and maintain.
In a typical Linux-Apache-(Postgres|MySQL)-Ruby environment JRuby with 
its additional requirement of Java comes with some
painful extra cost, which can otherwise be avoided.  In an 
java-enviroment, where part of the stuff should be done with Ruby+Rails
it might be the other way round.

My own observation is that JRuby is slightly faster than Ruby 1.8.7, but 
Ruby 1.9 is way faster than that.  But it depends on what Java
you use, what you do etc..

I would like to point out that the set of libraries available may be 
quite different.  Many Ruby-libraries use native c-code and are
unavailable in JRuby.

Another point is that operating-system-functionality is not really 
available in Java beyond what can be commonly implemented on
different platforms supported by Java.  So they are not easily accessed 
in JRuby either.  If such stuff is needed, native Ruby is better.
I have even used native Ruby to add Windows- and Linux-specific 
functionalities for accessing OS-features needed and hidden in Java
from a Java software.

So I would really recommend to carefully consider which one is better.

Best regards,

Karl

I would worry about changes to the Java language that would affect
JRuby. Ruby implementation is never going to be a big concern of the
Java devs, nor should it be.

On Aug 16, 1:45 am, AlwaysCharging
<goodg...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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?  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?

On Aug 30, 2:34 am, Karl Brodowsky
<lis...-y/VRGs7q77DqlBn2x/YWAg@public.gmane.org>
wrote:
> Dear All,
>
> I think Ruby and JRuby both have their advantages.  It depends on the
> environment which one is easier to integrate and maintain.
> In a typical Linux-Apache-(Postgres|MySQL)-Ruby environment JRuby with
> its additional requirement of Java comes with some
> painful extra cost, which can otherwise be avoided.  In an
> java-enviroment, where part of the stuff should be done with Ruby+Rails
> it might be the other way round.
I think the "cost" of the Java dependency is extremely low. Debian,
Suse, Redhat, Ubuntu...all the Linux distributions how have single-
command installs for Java that "just work". Pick a "Java 6"
or "Java
1.6" version and you''re ready to go. I would dare say
it''s at least as
easy as Ruby, and probably easier on peculiar systems that have Java
installs but no supported Ruby install.

It is for this reason JRuby has become the Ruby of choice for a lot of
people on Windows; install Java, unpack JRuby, and you''re done.
> My own observation is that JRuby is slightly faster than Ruby 1.8.7, but
> Ruby 1.9 is way faster than that.  But it depends on what Java
> you use, what you do etc..
Java 6+ should always be used for comparison, and if you''re
benchmarking or running a production server you should pass --server
to JRuby to use the optimizing JVM. We''re generally about on par with
1.9...faster at some things and slower at others.
> I would like to point out that the set of libraries available may be
> quite different.  Many Ruby-libraries use native c-code and are
> unavailable in JRuby.
Almost all libraries that require C code have equivalents in Java that
can be called directly from Ruby. In many cases, we''ve even ported the
C code or wrapped those libraries so that the gem versions will work
(like, Hpricot, Mongrel, etc). Many C libraries can also be called
directly from JRuby with FFI. In general, you probably have access to
*more* libraries from JRuby because you''ve got Ruby libs, Java libs,
and any C libs you can call with FFI.
> Another point is that operating-system-functionality is not really
> available in Java beyond what can be commonly implemented on
> different platforms supported by Java.  So they are not easily accessed
> in JRuby either.  If such stuff is needed, native Ruby is better.
> I have even used native Ruby to add Windows- and Linux-specific
> functionalities for accessing OS-features needed and hidden in Java
> from a Java software.
We''ve done a lot of work to implement OS functionality that
doesn''t
normally exist in Java (and isn''t planned for addition). Things like
FFI for programmatically calling C libraries, POSIX filesystem
functions, UNIX sockets, and more. We''ve worked very hard to make as
much OS-level code work well on JRuby as possible.

- Charlie

On Aug 30, 3:32 pm, AGoofin
<amor...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I would worry about changes to the Java language that would affect
> JRuby. Ruby implementation is never going to be a big concern of the
> Java devs, nor should it be.
Changes to the Java languages are extremely unlikely to be anything
but helpful for JRuby. There are also JVM-level features planned for
Java 7 which could help JRuby tremendously. I would not worry at all
about Java changes negatively impacting JRuby, and I should know.

- Charlie

Hej,

I have no doubt that JRuby is good stuff and I actually use it myself.

My own RubyForge-procect (long-decimal) is done in such a way that it
work both in Ruby 1.x and JRuby.

Best regards,

Karl