> <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">I've discovered that JRuby has a potentially better internal implementation of Thread, </span><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">> but I've not had a chance to play with it in anger yet - is it worth it?</span><br clear="all">
<div><br></div><div>Absolutely, without a doubt. We replaced a collection of heavily multi-threaded services (previously written in C#) with JRuby at my last job. I was honestly shocked how cleanly everything worked -- and if we ever had an issue, the JRuby authors provide better service in the #jruby irc channel than I've ever had from a commercial service contract. The only issue we really ran into was with C libraries wrapped in Java libraries which we then wrapped in JRuby. And that was never actually JRuby's fault.</div>
<div><br></div><div>> <span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">c) Multi-thread it, and at least on a single server be able to get 8x-16x performance </span></div>
<div><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">> increase </span><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">over multiple cores </span></div>
<div><br></div><div>Be careful about your expectations regarding multi-threading. While we found a marked performance improvement over our single-threaded solutions for anything we parallelized, we did not get an 8x performance boost from spinning up 8 parallel threads on an 8-core machine (or even a 16-core machine). The OS, other processes, your main (and other) threads, and context switching will all take a toll. As with any other performance improvements: careful, repeated measurements are your best friend.</div>
<div><br>Steven Deobald</div><div>C42 -- <a href="http://www.c42.in" target="_blank">www.c42.in</a> -- <a href="http://www.rubymonk.com" target="_blank">www.rubymonk.com</a></div><br>
<br><br><div class="gmail_quote">On 17 September 2012 23:27, Paul Robinson <span dir="ltr"><<a href="mailto:paul@32moves.com" target="_blank">paul@32moves.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
Now the recruiter rant post is on HN, let's move that discussion over there and talk about some proper Ruby stuff, eh? Please?<br>
<br>
Right, multi-threading, Ruby and Rails.<br>
<br>
This is causing me some pain, and I suspect it's because my mid-/low-level coding voodoo left my soul sometime around 2004. The beauty of a high-level language such as Ruby mixed with the fact I have not had to spend a moment thinking about memory management in 6 years has left my deeper coding brain soft, flabby and over-obsessed with meta-programming. A little like the fattened goose before Christmas (who are *so* into meta-programming, btw).<br>

<br>
On our current project we have a linear process that takes some time to process. It can easily be parallelised, because it's a discrete set of 20-30 steps that need to be done in order for each of the 'x' number of instances we're dealing with. Right now it can take hours, and for various reasons we need it to take seconds.<br>

<br>
My first stab at this was to look at benchmarking profiles and to look for single methods that were taking up a lot of wallclock time. There aren't any. We're not locking on I/O, we're not sitting in a single method for 30% of the time or anything, it's just a long drawn-out set of processes. Interestingly, the only headliner (at 8% of wall clock) is Kernel#Integer and we can't eliminate that.<br>

<br>
So we're moving straight to parallelisation.<br>
<br>
My first thought was to either:<br>
<br>
a) Split things up into separate fork'ed processes, but I don't like the bootstrap/tidy-up overhead that fork provides<br>
<br>
b) Throw it out to cloud-like infrastructures like Hadoop/MapReduce, but the problems needs direct SQL access and that can get messy<br>
<br>
c) Multi-thread it, and at least on a single server be able to get 8x-16x performance increase over multiple cores and maybe re-visit b) but with something a bit more pure Ruby-esque like delayed job, resque, etc.<br>
<br>
The problem is, multi-threading in Ruby - particularly in Rails with ActiveRecord model actions - kinda sucks. I can get it working, but it's painful. It doesn't look or feel graceful, and frankly I'm not sure if the internal methods for doing it are all that careful.<br>

<br>
Anybody here with experience in this little niche want to open up the discussion, provide some pointers and context, before I start poking around the internals of MRI? I've discovered that JRuby has a potentially better internal implementation of Thread, but I've not had a chance to play with it in anger yet - is it worth it?<br>

<br>
Thanks in advance,<br>
<br>
Paul<br>
<br>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote></div><br></div>