Publishing flamebait [Fwd: Pragmatic Bookshelf releases "From Java To Ruby"]

Levi Pearson levi at cold.org
Thu Jun 29 00:26:03 MDT 2006


On Jun 28, 2006, at 4:03 PM, Bryan Sant wrote:

> On 6/28/06, Hans Fugal <hans at fugal.net> wrote:
>> I'm also not very good at enterprise-level performance testing/ 
>> thinking,
>> but I'll venture that insofar as rails is not hindered by the ruby
>> threads implementation it's by working around the limitations.  
>> What are
>> the limitations, exactly? In my mind the primary problem is that  
>> if you
>> block a thread in certain ways, you block the whole process. Aside  
>> from
>> that, a virtual thread isn't all that different from a real  
>> thread, and
>> if your program is a primary contender for resources you will  
>> probably
>> not notice much detriment due to scheduling.
>>
>> Maybe Stuart or someone else has more insight into this than I do. If
>> not, I can ask the URUG people or maybe the ruby-talk list, I suspect
>> someone there would have a better answer.
>
> Your application will get zero benefit from multiple CPUs/cores if you
> don't use real threads.  On a single CPU (and single core) system,
> this doesn't matter much (as you've described).

That's only true if you limit yourself to a single instance of your  
application, which would be a rather silly thing to do in the case of  
web programming.  If you design your application such that requests  
can be handled transparently by multiple instances of your  
application, not only do you get to scale across the CPUs in a single  
machine, but you can also scale across multiple machines!

And while we talk about scaling, you might want to look at how a  
system using OS threads compares to one using "green" threads as the  
number of threads rises.  OS threads have a pretty serious memory  
overhead and context switching delay, and highly multithreaded  
programs tend to break down much faster under load with OS threads  
than "green" threads.  This can be worked around to some degree, of  
course, with constructs like thread pools, but at cost of the  
complexity of the program.

Certainly there are advantages and disadvantages to either thread  
implementation (as there are to using threads as opposed to other  
concurrency mechanisms), and it's better to know about them and make  
informed decisions than to just use OS Threads because that's what  
everyone else seems to say is best.

		--Levi



More information about the PLUG mailing list