The Ruby Reflector

A lot of people talk about the GIL (global interpreter lock) in Ruby 1.9 as a death knell for concurrency. For the uninitiated, the GIL disallows multiple CPU cores from running Ruby code simultaneously. That does mean that you'll need one Ruby process (or thereabouts) per CPU core, but it also means that if your multithreaded code is running correctly, you should need only one process per CPU core. I've heard tales of six or more processes per core. Since it's possible …

• Topics: Ruby, Ruby on Rails, JRuby, Node.js, Merb
• Merbist: Discussion with a Java switcher
• A Rubyist Railstastic Adventure: Threads (in Ruby): Enough Already
• RubyLearning Blog: RPCFN: The Game of Life (#11)
• Merbist: Ruby object allocation & why you should care
• Fingertips: Ruby and Rails 2010
• The Queue Blog: Link dump for August 11th

Developers hankering for more performance from their Rack and Rails applications are using Ruby 1.9 fibers and event-based EventMachine -driven libraries as a way to boost the performance of their applications - in opposition to scaling by merely running multiple processes or using threads.

It's no secret that thread-based development can be Hard™, even if you didn't have to deal with Ruby quirks like autoloading not working properly and the GIL ( Global Interpreter Lock…

• Topics: Ruby on Rails, Ruby, Rack, Ilya Grigorik, EventMachine
• Intridea - Company Blog: Intridea Insider: Chris Selmer
• Zen and the Art of Programming: Padrino: a Ruby framework built upon Sinatra
• Article RSS Feed: June 2010 Meeting
• upstream agile - software: Experimenting with node.js/mite
• RubyLearning Blog: RPCFN: Business Hours (#10)
• Jake Scruggs: Why I Left Obtiva

Rails and MySQL go hand in hand. ActiveRecord is perfectly capable of using a number of different databases but MySQL is by far the most popular choice for production deployments. And therein lies a dirty secret: when it comes to performance and 'scalability' of the framework, the Ruby MySQL gem is a serious offender. The presence of the GIL means that concurrency is already somewhat of a myth in the Ruby VM , but the architecture of the driver makes the problem even worse. Let's take a look under the hood.

• Topics: Ruby on Rails, MySQL, VM, Drizzle, ActiveRecord
• codahale.com: When Formality Works
• A Fresh Cup: Double Shot #683
• The messagepub Blog: How-To: Rack Middleware for API Throttling
• Ruby Inside: Cramp: Asychronous Event-Driven Ruby Web App Framework
• has_many :bugs, :through => :rails - Home: Websockets made easy with Cramp
• Luigi Montanez: Presentation on Thin

…simply broken and Ruby's thread implementation does not scale at all due to the GIL.

Here's a sample action which uses memcached and the database. There's nothing odd here - it's the same old Rails API and codebase we are used to as Ruby developers, it just executes differently under the covers.

class HelloController < ApplicationController def world site_ids = Rails. cache . fetch 'site_ids' , :expires_in => 1. minute do Site. …

• Topics: Ruby on Rails, EventMachine, Ruby, Web server, Rack
• A Fresh Cup: Double Shot #666
• igvita.com: Consuming XMPP PubSub in Ruby
• 4 Lines of Code: RabbitMQ and AMQP in Ruby
• Engine Yard Ruby on Rails Blog: Using the Rubygems Bundler for Your App
• oldmoe: Ruby Strikes Back
• Ruby Inside: EventMachine: Get Excited By Scalable Non-Blocking I/O

Getting concurrency in Ruby is tough: Ruby 1.8 threads are green so they don't execute concurrently. Ruby 1.9 threads are native but they don't execute concurrently due to the GIL (global interpreter lock) necessary to ensure thread-safety with native extensions. Only JRuby provides a stable, concurrent Ruby VM today. On top of that, writing thread-safe code is tough - code execution is non-deterministic and so everyone gets it wrong, the code is hard to test and bugs painful to track down.

• Topics: Ruby, Ruby on Rails, Fibers, SimpleDb, EventMachine
• Litany Against Fear: Sinful Ruby Notes
• David Bolton Strikes Again: Vim
• Rails Inside: MonkeySupport: Boosting Rails With Patches of C
• Lindsay Holmwood - auxesis' musings: Why scripting your server installs is a bad idea (and configuration management is awesome)
• No Strings Attached: URL regex pattern in Rails
• Dead Programmer Society: Fear And Loathing At RailsConf 2009

…0.5 beta 1 ), and the benefits are numerous: machine code compilation, true concurrency (no GIL), a working JIT, and even ahead of time compilation ( AOT)!

In other words, MacRuby is now a true Ruby compiler. You can write a HotCocoa app, leverage native POSIX threads, or even take advantage of Apple's Grand Central Dispatch ( GCD) and then compile your program and distribute it as a binary to any OSX user.

With 7 members on the team and a growing community …

• Topics: VM, MacRuby, JRuby, Rubinius, IronRuby
• Merbist: MacRuby 0.5 beta 1 and Textorize
• Zen and the Art of Programming: Getting MacRuby's compiler to work
• Floehopper: Mocha Release 0.9.6
• Phusion Corporate Blog: Ruby Enterprise Edition 1.8.7-20090928 released
• MacRuby Posts: MacRuby 0.5
• Programblings: Rubinius for the Layman, Part 3 - Try Rubinius in 20 minutes

…still incomplete version of Ruby), which brings JIT, removal of the dreaded GIL ( Global Interpreter Lock), native threads, GCD ( Grand Central Dispatch) for multicore computing, and a whole new set of features found in the release announcement to the table.

The most important new feature is the presence of a compiler. That's right, thanks to this release, Ruby code can now become highly optimized executable code. How awesome is that? I can sense that you're pumped …

• Topics: MacRuby, Ruby, Low Level Virtual Machine, Global Interpreter Lock, Grand Central Dispatch
• A Fresh Cup: Double Shot #629
• Merbist: MacRuby soon to reach a new milestone
• AlternateIdea - Home: MacRuby: The Path Forward
• MacRuby Posts: MacRuby 0.5 beta 1
• Nikos D.: More speed comparisons of Ruby 1.8, Ruby 1.9, JRuby, Rubinius and MacRuby using Graticule
• rentzsch.tumblr.com: C4[3] Registration Open