A big topic in the world of Ruby this year has been how to get more out of Ruby, specifically, how to get more done in parallel. The topic of concurrency, though, is one fraught with misunderstanding. This is largely due to the complexities of not only thinking about multiple things at once, but the limitations of Ruby implementations and operating systems.

In this article, I’ll lay the groundwork for understanding the difference between concurrency and parallelism. Then, I’ll look at how a programmer experiences them.

Concurrency vs. Parallelism

This has been discussed many times, but I sometimes still have difficulty with it. Let’s first break down the definitions of these two words:

• Concurrent: existing, happening, or done at the same time
• Parallel: occurring or existing at the same time or in a simple way

Hmm, ok. Well, that hasn’t improved our thinking about these two topics. We need to dig deeper into how the world of computing applies to these words. Rather than looking at the abstract, let’s instead consider some real world examples.

A “Real World” Example

Let’s say you’ve sat down for the evening to complete tomorrow’s homework. This evening you’ve got both Math and History worksheets to fill out. Tonight for some reason, you decide to do one problem in Math, then one problem in History, then back to Math, etc until all the problems are done.

In the parlance of computing, you’re now doing your Math and History worksheets concurrently. This is because your Current task list includes 2 items: Math worksheet and History worksheet.

Now, clearly you the reader can see a problem here. By switching back and forth, completing your homework will probably take longer than if you did the complete Math worksheet then did the History worksheet. In other words, if you did the worksheets in serial.

So, if concurrent means “having multiple outstanding tasks at once”, then what is parallel? Parallel is the ability to make progress on multiple tasks simultaneously.

Let’s say you’ve been asked to read the book One O’Clock Jump by Lise McClendon. You also need to drive down to San Diego for Comic-Con. Thankfully you find that One O’Clock Jump is available on audiobook!

You can now listen to the book while driving. You’re simultaneously making progress on two separate tasks. This is the equivalent of parallelism in computing.

I hope that these real world examples help illustrate the difference between concurrency and parallelism. Now let's apply this newfound knowledge to Ruby.

Back to Ruby

One reason this problem can be difficult to understand is because Ruby only provides a single mechanism for concurrency. But, whether or not these Threads are parallel depends on a number of factors.

MRI 1.8

Let’s look at MRI 1.8 (and MRI forks such as REE) to begin with, because it has the simplest model. MRI 1.8 uses a technique known as “green threads” to implement Threads. This means that every once in a while (around 100 milliseconds), the program says “oh, I should let another thread run now!” This saves the current info into the current thread and restores another thread. This is exactly like our homework example above. We can have as many things as we’d like in our task list, but we can only make progress on one of them at a time.

There is a wrinkle in the concurrency/parallelism game that I haven’t mentioned before now. This wrinkle is IO, namely how Threads interact when waiting for some external event. MRI 1.8.7 is quite smart, and knows that when a Thread is waiting for some external event (such as a browser to send an HTTP request), the Thread can be put to sleep and be woken up when data is detected. This simple consolation improves the usage of Threads so much that for a very long time the MRI 1.8.7 model was good enough for all Ruby programs.

MRI 1.9

Switching back to Ruby implementations, let’s look at MRI 1.9. As has been previously reported, MRI 1.9 removes the “green threads” we had in MRI 1.8 and uses native threads to implement the Thread class. Now, what are these “native threads”? These are are units of concurrency that the underlying operating system is aware of. A big reason to switch to use native threads is that it vastly simplifies the implementation of Threading. The operating system handles the low level parts of saving and restoring Thread information in a completely transparent way. Additionally, letting the OS know what parts of a program should be concurrent allows it to use the full resources of the computer to make that happen. In this modern world, that means using multiple cores.

Up until now, all we’ve talked about with Ruby’s Threading model was about concurrency, the ability to have multiple outstanding tasks at once. Now when we add in the idea of multiple cores, we can finally talk about parallelism. When a computer includes multiple cores (which is pretty much every computer now), those cores can run different code simultaneously, providing true parallelism. When a computer only has one core, there is no true parallelism, instead there is just simple concurrency, even at the OS level. The OS manages all the processes and threads in the system the same way you handled your Math and History worksheets, doing one for a little while, then grabbing another one.

Back to multiple cores though. Now that there is the opportunity to run things truly in parallel, we have to look at if Ruby can take advantage of that. Since MRI 1.9 uses OS threads, it can actually spread out your Ruby Threads to multiple cores!

Unfortunately, MRI 1.9 prevents the Ruby code itself from running in parallel by requiring that any thread running Ruby code hold a lock. This lock is commonly knows as the GIL (Global Interpreter Lock) or GVL (Global VM Lock).

There are a few reasons the GIL to exists, but for this discussion we will say that it’s because the non-Ruby parts of MRI 1.9 are not thread-safe. This means if data were manipulated by multiple threads at the same time, the data could become corrupt. The important thing for this post is how it applies to parallelism: the GIL inhibits parallelism within Ruby code.

MRI 1.9 uses the same technique as MRI 1.8 to improve the situation, namely the GIL is released if a Thread is waiting on an external event (normally IO) which improves responsiveness. MRI 1.9 also includes an experimental API that C extensions can use to run some C code without the GIL locked to utilize parallelism. This API is very restrictive though because no Ruby object may be accessed in any way while the GIL is not held by the current thread.

That about sums up the situation with MRI 1.8 and 1.9 with regards to concurrency and parallelism. Both provide concurrency of Ruby code, but neither provide parallelism of Ruby code.

Rubinius

Let’s take a quick look at other Ruby implementations where things are a bit different than MRI. I’ll start with Rubinius, since it’s the one I’m most familiar with. Rubinius 1.x also had a GIL and worked pretty much the same as MRI 1.9. With the upcoming 2.0 release though, the GIL will be removed, allowing Ruby code to run fully concurrent and fully parallel. We think this opens up a lot of uses for Ruby (parallel algorithms, etc) that Rubinius couldn’t handle well previously.

JRuby

JRuby layers the Thread class on top of Java’s thread class, so the threading model is whatever the JVM supports. That being said, OpenJDK is the primary JVM; it puts a Java thread directly onto an OS thread with no GIL. Thusly, JRuby almost always has full concurrency and parallelism available to it.

MacRuby

MacRuby also uses Cocoa’s NSThread as its abstraction, which runs without a GIL. So, this is another fully parallel implementation.

Maglev

Maglev runs directly on top of a Smalltalk VM and thusly layers the Thread class on top of a concept called Smalltalk Processes. In this case, the GemStone VM implements Processes in the same way as MRI 1.8, namely via “green threads” that don’t expose concurrency to the OS, and therefore, have no parallelism.

IronRuby

Lastly, IronRuby layers Thread directly on top of CLR’s threads without a GIL.

Conclusion

I hope that this helps to clear up what concurrency and parallelism are and how the different Ruby implementations address them. Having this understanding is critical for discussing and understanding topics such and thread-safety of libraries and performance of applications.

In future posts, we’ll look to build on this knowledge to help you make the best use of Ruby!

A lot has changed in the intervening years with both Engine Yard and Rubinius but nothing has changed the focus on building Rubinius as a first class Ruby environment that is easy to use. Engine Yard has seen significant movement into the cloud/platform services realm and Rubinius has meanwhile begun to push the boundaries of Ruby performance. We've been building software and services to get us to this exact point in time and I couldn't be more excited. Rubinius now has all kinds of tools for making a developer's life easier, from builtin profilers to external monitoring.

Enabling Access to Rubinius on AppCloud

Now for the nitty gritty. We're going to be making Rubinius available in Alpha (as a part of our Beta Program). This means it will only be available to users that specifically request it. To request to have Rubinius available as one of your Rubies, fill in this form for each AppCloud account email. We'll flip a bit in your account and you'll have Rubinius as an option when configuring your instances.

Support for Rubinius on AppCloud

As a trial program, we want Alpha users to report issues back to us as quickly as possible. This will help us get them fixed and help smooth out the rough edges before Rubinius is moved into Beta, and then finally made available to all our users.

Please initiate Support requests and feedback via the EY Beta discussion group.

Thank You

On a final personal note, I'd like to thank all the people who have contributed to Rubinius over the past many years. Your help, no matter the size, has helped us get to this point. I can't wait to see where users take Rubinius on AppCloud!

Rubinius 1.2 was just released and is available at http://rubini.us. There are a number of new features and improvements since 1.0.

LLVM 2.8

We've upgraded to using LLVM version 2.8, the latest released version. LLVM powers the high performance compiler Rubinius uses to compile Ruby code all the way down to machine code. This brings some minor performance improvements related to better optimizations, but this mostly paves the way for future high-level optimizations that we'll be implementing with new LLVM 2.8 features.

Bytecode Verifier

More and more people are beginning to use Rubinius as a platform for other languages, not just Ruby. This is a development we're all super excited about, but it meant we needed to get a little more serious about making sure that bytecode can't crash the VM. Previously, we got along fine with no verifier simply because there was only one piece of code that generated Rubinius bytecode, the Rubinius compiler. Now with others also doing so, we needed to make sure they're generating valid bytecode. The bytecode verifier is a VM operation that is performed lazily, when a method is first invoked. It makes sure that the bytecode is consistent, for instance, only using the amount of stack it has requested and only using the proper number of local variables. With this new safety net in place, people can feel much more confident about generating their own bytecode without causing any hard crashes in the system.

Memory Efficiency

Ruby is being used for larger and larger software projects these days. This makes how system memory efficiency very important. There are two measures of memory efficiency: growth stability and memory usage per object. Growth stability is largely a feature of the garbage collector, and is something that Rubinius has done quite well for some time now and so we focused on improving the memory usage per object.

Specifically, how an object stores its instance variables in memory. Because Ruby does not require instance variable declaration, the simplest way to model instance variables is with a hash. This is precisely what Rubinius used to do. The issue is for classes that have a small number of instance variables. In this case, the size of the hash table is substantial, needing more than 100 bytes of memory just to store one word (either 4 or 8 bytes)! And so we set about to try and reduce this overhead. Because Rubinius uses so many Ruby classes internally, we knew that a fix would have immediate benefits.

The new code is based upon an easily observable assumption about a class, namely that it defines the vast majority (usually all) of its methods before an instance of the class is created. We exploit this by running some code the first time an instance of a class is created which looks at all methods available to instances of this class. This means all methods defined in the class itself, its superclasses, and any mixed in modules. From the methods, we build a table of all instance variables those methods use.

Now we can construct a very good picture of how memory should be laid out for instances of this class, allowing us to store the instance variables in memory without needing a hash table. The memory usage typically goes from 100 bytes to 8 bytes on a 64bit machine. Quite a savings!

Debugger

A good debugger is invaluable when working on code of any kind. One of the big additions since 1.0 is the built-in debugger. Gems such as ruby-debug wouldn't compile, let alone work, because Rubinius doesn't share any internals with MRI.

We decided to take a different approach than most debuggers for languages. Typically, the debugger is delivered and used via some kind of command line interface only. We wanted a command line interface, but we didn't want it to be the only way into the system.

So, instead we built a Debugging API into the VM itself and built the CLI debugger on top of this API. This means it's available to be used by other projects that want to build new and innovative debuggers. In fact, the CLI interface we ship should be considered a kind of reference implementation. It's a bit short on features, but shows easily how to use the API and build upon it. We've already had people begin to port their debugger logic over to using the Rubinius API so that existing debuggers can be plugged into Rubinius simply.

Using the debugger is easy:

require 'rubinius/debugger'
Rubinius::Debugger.here

This will drop the code into the debugger at the .here method call, allowing you to inspect the call stack and objects on it. You can also use the -Xdebug option to rbx, which will start the debugger before loading the initial program, allowing you to set breakpoints before loading code.

For 1.2, we've introduced a special ruby-debug shim gem. This gem doesn't contain ruby-debug, but instead emulates the most common entrance point to it and invokes the built-in debugger. This means that projects such as Rails which have ruby-debug support integrated in work out of the box.

In future releases, we'll continue to improve on the debugging APIs as well as the CLI interface. So if you've got ideas for improvement, be sure to let us know!

Also we're looking for a list of projects that begin to add support for the debugging API. This includes frameworks like Rails and editors such as Emacs, VIM, Textmate, etc. If you're interested in adding support for your favorite project, let us know so we can help!

Query Agent

Query Agent (QA) is yet another tool that developers can use to debug and introspect their running programs. It provides the ability for the VM to export all kinds of low level data such as statistics about the garbage collectors. In addition to raw stats, it provides the ability to trigger functionality by reading and writing values.

For example, to get a live backtrace of all threads, simply read the system.backtrace variable. The values returned are calculated on request and thus reflects the current state of the system.

Implementation wise, Query Agent is a socket based API that is implemented directly by the VM. We opted to use BERT as the wire protocol, which allowed us to easily write a ruby client using the existing BERT encoder/decoder gem.

We hope that people will begin incorporating Query Agent support into their monitoring tools, allowing them to get very rich data and control of their ruby processes.

Heap Dump

Lastly, we have integrated a memory debugging tool directly into the VM. Heap Dump provides the ability to write out the entire object graph to disk in a stable, portable format. That file can then be read back in and analyzed. A very common analysis that is performed is simply to find out how many objects of each class exist in the system. This knowledge alone can help developers figure out object leaks that might exist in their code. There are currently two interfaces to Heap Dump, one in Ruby and one via the Query Agent.

In Ruby:

Rubinius::VM.dump_heap("/path/to/file")

and via the Query Agent:

set system.memory.dump /path/to/file


By having access via Query Agent, it become possible to debugging production processes offline.

We've only begun writing tools to analyze the dumps, which is available at
https://github.com/evanphx/heap_dump.

Beyond 1.2

The team has been doing great since the 1.0 release, expanding Rubinius compatibility and improving performance. Coming up in the next few months, we've got three key features we're really excited about: 1.9 support, Microsoft Windows support, and true concurrency. These are big ticket items that we've been asked about a lot, and that will push Rubinius into more and more developers hands.

I'd like to thank everyone for all the support this year. It's been a wonderful year full of great releases. Seeing Rubinius continue to grow and blossom in 2011 should be even better!

Now it is time for Yehuda to broaden his horizons. After 4 years working on Rails at Engine Yard he gets to focus on another one of his passions in JQuery and mobile development - an offer he couldn't refuse. He will be a founding employee of a new startup in the mobile applications space, with Carl joining him. They have both been passionate full-time members of the Rails team and we want to be the first to congratulate them on this new opportunity. As always we are flushed with pride on the success of our Engine Yard Alumni!

We aren't saying goodbye to Yehuda though, he'll remain a part of the extended Engine Yard family. Soon Engine Yard will be launching a Technical Advisory Board with Yehuda as a founding member. The Board will become a valuable forum for our customers, partners and other stakeholders to contribute feedback and perspective to the Engine Yard team to help drive the product features and capabilities. In addition to his adviser role on the new Board, Yehuda and Carl are going to continue working on Rails, beginning with the 3.1 release. We know that they'll continue to flourish, helping to push Rails forward as one of the best web development environments.

While we'll miss the daily presence of Yehuda and Carl, this change is well timed as we transition our focus from engineering to evangelism for Rails 3.0. We believe that Rails is the future of the web development industry and we want to ensure widespread and successful adoption of the framework. Additionally, Engine Yard will also continue to invest its Engineering talent into open source development throughout the Ruby/Rails ecosystem.

On a personal note, I'll deeply miss having Yehuda and Carl around as coworkers. I wish them all the best and know that they'll continue to find success in their new endeavor.

In today's post, I'll be giving an overview of the various players involved in the path that code takes to get from source to machine code. Without further ado, I'll jump right in.

Melbourne Parser

This is the first step. The parser takes Ruby source code as input and calls for each element to create an internal representation of the code: the AST. (lib/ext/melbourne)

Compiler

The compiler takes the AST that the parser created and analyzes it, creating bytecode in the form of a CompiledMethod and InstructionSequence. (lib/compiler)

Bytecode

A CompiledMethod object contains an InstructionSequence object, which is the raw bytecode which will perform the semantic actions of the Ruby source code. (lib/compiler/iseq.rb)

Virtual Machine

The VM itself then executes the bytecode using a simple interpreter. A key data structure used in this evaluation is the VMMethod, which is an internal mirror of a CompiledMethod, but translated into constructs that are easier to interpret. As the VM interprets a VMMethod, it uses InlineCache objects to speed up method dispatch. In addition, these InlineCache objects remember profiling information about what methods they have seen. This information is later used by the JIT.

The VM also increments a call counter on the VMMethod at a few critical points (on start and on backward branch). This call counter is what controls when the JIT kicks in. When the call counter reaches some predetermined value (controlled via -Xjit.call_til_compile), the first stage of the JIT kicks in.

Method Chooser

Now that a call counter has reached the proper level, the JIT is ready to kick in. The JIT could simply take the method whose counter has hit the level, but instead it starts the search. It's looking for a good method to JIT, which it finds by looking up the call stack.

The reason it does this is because the JIT has the ability to inline methods into methods that call them. We're exploiting the fact that the call stack shows not just one method heating up, but a whole chain of them (vm/llvm/jit:compile_callframe). So we walk up the call stack, looking at each method along the way, and asking ourselves: could this method be inlined into the one that called it? If the answer is yes, we move to the next method. By doing this, we're able to inline methods along hot paths in code, which yields better speeds.

Compiler Thread

Now that we've picked a good method at which to start the JIT process, the method is placed into a queue. This queue is then automatically emptied by another native thread, which is always running. It's in this background thread that the rest of the JIT process takes place.

Using a background thread means that the Ruby code is free to continue to run while the JIT runs in the background. This means that the JIT imposes virtually no slowdown, because it never stands in the way of running Ruby code (vm/llvm/jit:compile_soon).

The JIT thread pops an entry off the queue and begins compiling it. Because the JIT uses LLVM to perform low level optimizations and machine code generation, we need to translate the method into a structure that LLVM understands. This structure is the LLVM IR.

To convert the method, we walk through the bytecode and call methods on a JITVisit object (one for each kind of bytecode). The JITVisit class uses LLVM's IRBuilder class to build a big tree data structure that represents the actions that should be taken.

A simple example is that a goto bytecode instruction is translated into a Branch object and inserted into the IR. For most bytecode, the process is fairly straightforward, there being a simple set of IR objects to generate per bytecode.

Method Inlining

The most complicated bytecodes to generate IR for are the send instructions. This is because it's at these points that we have the opportunity to inline a method. When a method is inlined, the code to perform the method is inserted where the send instruction would normally be. This eliminates any calling overhead and allows LLVM to optimize more.

At this stage, control is handled to an Inliner object. The Inliner will only inline a method if it can see that the method was the the primary method called at a particular send instruction. Because Ruby is a dynamic language, any method call can always invoke a brand new method. But in reality, that happens rarely. Instead, most method calls always end up calling the same method over and over again. The profiling information that the InlineCaches have been gathering allows us to see that this is the case and perform inlining.

One constraint that the Inliner has is that it needs to avoid over-inlining. Over-inlining causes the generated function to become extremely large and slower than it would be if there were no inlining. To do this, the Inliner keeps track of the cost of a inlining. For every method that is inlined, the cost increases. When the cost reaches a threshold, no more inlining takes place.

Now that the Inliner has decided to go ahead and inline the method, it must insert a guard before the inlined code. This guard makes sure that the object is still of the type seen in the profiling information, and that therefore the inlined method code is the proper code to run. The generated IR for this looks something like:

if(obj->class == profiled_class) {
 result = inlined_code_for_method_name;
} else {
 result = obj->send method_name, …;
}

This allows Ruby code to continue to be dynamic, but exploits those points in the code where the dispatch is actually static.

After the JITVisit class has finished, control is handed off to optimize and generates machine code.

LLVM Optimization

Up to now, we've simply been constructing information to feed to LLVM. Now we actually hand over the IR to LLVM. The first thing LLVM does is run a number of optimization passes over the IR. This cleans up the IR and makes it quite a bit more efficient. At this stage, the IR can be reduced in size by five to ten times by remove redundancies and reordering.

LLVM Code Generation

Finally, the optimized IR is run through LLVMs code generator. This code generator is fairly complex, but its API is extremely simple. When the generator finishes, it returns a function pointer that can be called to execute the code. We put this function pointer into a special slot on the original CompiledMethod.

By default, this slot in the object holds a pointer to the function that implements the interpreter. By swapping them, any future calling of the method automatically uses the new JIT'd version.

Deoptimization

Because Ruby is so dynamic, there are cases where JIT'd code must be discarded. The primary example is where a method that was inlined is redefined. In this case, the VM keeps a table to know all methods that inlined the method being redefined. It resets those methods back to using the interpreter and tags the JIT'd code to be discarded. Because the method has been reset, it can now be JIT'd again later, incorporating the newly redefined method.

So those are the systems that interaction to make speed up Ruby. The process can achieve speeds up by as much as 10x over non JIT'd code. We've only begun to scratch the surface of the techniques we can use to strip even more dynamic aspects of the code away and make it faster. 2010 is going to be an exciting year.

In this series, Evan Phoenix, Rubinius creator and Ruby expert, presents tips and tricks to help you improve your knowledge of Ruby.

One of the most common is memoization. This is the technique of calculating a value once, then saving the result and transparently substituting it for the code that calculated the original value.

Here's a short example:

def size_of_universe
 @size ||= Universe.find.size
end

Here, we've calculated the size of the universe and then saved the result into the @size ivar. This way, the next time size_of_universe is called, the previously calculated value is returned.

We've already gone over one of the simplest and most basic techniques, above. This technique uses the ||= operator to run the right hand side if, and only if, the left hand side is not true. It's short and sweet, rarely confusing the user.

Another technique that has been seen in production code uses ObjectSpace._id2ref. While this is becoming a common technique, it has a number of problems that we'll look at today.

Here is an example of using this technique:

obj = Universe.find.size
 
eval <<CODE
def size_of_universe
 ObjectSpace._id2ref(#{obj.object_id})
end
CODE

This technique is used frequently with metaprogramming, when you want to embed a specific object directly into a generated method. People use this technique because, at first glance, it removes any kind of data dependency on the generated code and obj. There is no ivar to make sure is in scope, no constant, etc. But, in fact, this technique masks some rather terrible bugs.

This technique basically uses the whole Ruby process as a big table, leveraging the ability to easily get the table index for an object and convert that table index back into the object.

The primary issue stems from the fact that Ruby is a garbage collected language. Even though the code has requested the object_id for an object, that is not enough to keep the object alive. So if the only reference to the return value from #size was obj, when this method returns, obj becomes garbage.

So what happens when you run #size_of_universe and obj has been garbage collected? Well, a few things can happen:

1. id2ref will raise a RangeError, saying that the id no longer points to an object.
2. A random object will be returned.

The second scenario is probably the strangest, but this can be observed. This bizarre _id2ref behavior occurs because the return value from #object_id is actually the address in memory of the object itself. This means that when the GC runs and collects the object, and then the allocator puts another object in the same place (which is exactly what an GC does), whatever object happens to be there is returned. This is essentially the same as a hanging pointer bug in C.

Lastly, the implementation of #_id2ref varies wildly between different Ruby implementations, each having different performance and different potential bugs. Due to these factors, using #_id2ref in production is even more nebulous.

So what's a simple alternative?

UNIVERSE_SIZES = [ ]
 
idx = UNIVERSE_SIZES.size
UNIVERSE_SIZES << Universe.find.size
 
eval <<-CODE
def size_of_universe
 UNIVERSE_SIZE[#{idx}]
end
CODE

This seems silly if there is just a single value in UNIVERSE_SIZES, but the expectation here is that you might be generating many methods with values that need to memoized. In the example above, we're storing methods in an Array that is in a constant, which will keep the value alive from a GC standpoint. This avoids the bugs that #_id2ref has.

So hopefully if you need to memoize, you won't use _id2ref. There are a number of alternatives, most of them are better than worrying about the bugs that #_id2ref can easily introduce.

In this series, Evan Phoenix, Rubinius creator and Ruby expert, presents tips and tricks to help you improve your knowledge of Ruby.

Most Ruby programmers are familiar with the most common one:

Integer#times
  100.times { |i| p i }

Integer#times counts from 0 up to 99, yielding the current number to the block. This a simple, expressive way to execute some code a number of times.

But there are cases where you want to start counting at a number other than 0, no problem:

Integer#upto
  10.upto(20) { |i| p i }

This prints out 10, 11, 12, until it hit 20. It increments by 1, and you'll notice it is inclusive, meaning that in this case we yield 11 items, not 10.

Going up is nice, but sometimes you need to go down, so use #upto's sister:

Integer#downto.
  20.downto(10) { |i| p i }

If you need a little more control over your iteration, you can use:

Range#step
  (10..20).step(2) { |i| p i }

This will print 10, 12, 14, 16, 18, 20.

Now, in this case, we've introduced a Range, which most Ruby programmers are familiar with. It is basically an object that expresses a beginning and an end — in this case, 10 and 20. Range has another trick up it's sleeve:

  (10...20).step(2) { |i| p i }

You'll notice the 3 dots instead of 2. This indicates that this range is exclusive of the end, not inclusive. So 20 is the terminator, but is not in the set of valid values itself.

Range also support #each:

  (10..20).each { |i| p i }

This works exactly the same as Integer#upto. I personally prefer Integer#upto, because I feel it expresses the operation better.

Another domain is counting on a collection. Before 1.8.7 and 1.9, there was pretty much only one method to help you with doing that: Array#each_with_index.

  [:foo, :bar, :baz].each_with_index { |sym, index| p [sym, index] }

This prints out [:foo, 0], [:bar, 1], and [:baz, 2].

This is nice, but it's pretty limiting because the only place you've got that index is with simple iteration. Say you wanted to map the Array and take the position into account — you'd have to do:

  ary = [1, 3, 5]
  i = 0
  ary.map { |element| x = element * i; i += 1; x }

It's kind of messy to just take the position into account. So with 1.8.7 and 1.9, Enumerator support was baked into most methods which makes this much simpler!

  ary = [1,3,5]
  ary.map.with_index { |element, index| element * index }

For those that haven't seen Enumerators yet, you're saying "Hey! Where did the block to map go!" Well there isn't one. Array#map, when passed no block, returns a Enumerator object. This object, when you call #each, calls the original method on the original object and passes the block along. To begin with, this provides external iteration, but it also gives Ruby a place to add iteration alteration methods, such as Enumerator#with_index. Now you never need to use a while loop again!

See you next time!

Update

1.8.7 is a bit inconsistent about when Enumerators are returned. You can instead do:

ary.dup.map!.with_index { |e,i| ... } 

Or, as a commenter pointed out:

ary.to_enum(:map).with_index { |e,i| ... } 

In this series, Evan Phoenix, Rubinius creator and Ruby expert, presents tips and tricks to help you improve your knowledge of Ruby.

Lets say we want to add a new numeric class called Money, which contains the number of dollars and cents:

class Money
  def initialize(dollars, cents=0)
    @dollars = dollars
    @cents = cents
  end

  attr_reader :dollars, :cents
end

Now, lets say we'd like to have Money be able to interact with all integers nicely, with an integer representing a number of whole dollars. It's not too hard add a + method to do that:

class Money
  def +(other)
    case other
    when Money
      Money.new(@dollars + other.dollars, @cents + other.cents)
    when Integer
      Money.new(@dollars + other.to_i, @cents)
    else
      raise ArgumentError, "Unknown type!"
    end
  end
end

but we'd also like to be able to do:

allowance = Money.new(5)more = 1 + allowance

Trying this straight away, you'll receive a message about Money not being able to be coerced to a Fixnum. This gives you a hint as to how to allow Money to interact with Fixnum better. We need to teach Money how to interact with the rest of the numeric tower, which we do with just one method:

class Money
  def coerce(other)
    [self, Money.new(other.to_i)]
  end
end

now we can do more = 1 + allowance and we see that we get #.

Wonderful! Fixnum#+, seeing the argument isn't a Fixnum, uses the coerce protocol. This is a simple double dispatch protocol, which gives the argument the ability to change the values being operated on, then call the original method again. We simply return an array of the new values to use, here we convert the argument to a Money object, and then + is called again on the first element in the Array, passing the second as the argument.

Lets say we'd like "1 + allowance" to return 6 instead. Easy!

class Money
  def coerce(other)
    [@dollars, other.to_i]
  end
end

Now, for your homework, make Money work also with Floats! See you next time...

In this post, I'll walk you through how Ruby code begins as text and is converted into bytecode. In a follow up post, I'll go from bytecode to the machine code itself.

So let's get started: in the beginning, there was Ruby code (and the compiler saw it was good)!

def foo(a,b)
  a + b
end

This is a simple file dot-rb file written to disk—the currency of Ruby developers. So first things first. To get this code into the environment, the code is parsed into a tree of Node objects. In Rubinius, this is typically done using the parser we've imported from 1.8.6. This tree of Node structures is a C data structure, and it's what 1.8 uses for direct execution, simply reading the tree and running code based on the structure of this tree.

The issue with directly executing a tree structure is that it's fairly inefficient. There's no simple way to move around the tree, and you get a lot of redundant operations performed at the CPU level to execute even the most trivial of Ruby code.

So what we want to do instead is lower this tree to bytecode, which is an easier representation to execute efficiently. We start by translating the tree of Nodes in C into S-Expressions (sexps) using a variant of Ryan Davis's ParseTree. I'd be remiss if I didn't mention that sexps can also be produced by using Ryan's ruby_parser project, which is what Rubinius uses for bootstrapping itself within MRI.

The neat part about this transform is that we've now got a representation of the program as normal Ruby objects. This allows us to write our bytecode compiler in Ruby itself, which is the phase that takes the sexp and transforms it into an internal tree of AST instances.

An astute reader will notice that not two paragraphs ago, we already had a tree of Nodes representation. This is an inefficiency in the current compiler, and one that Brian Ford is actively working to eliminate. The upside of the transform is that while it was a tree of Node structures in C before, we've now got a tree of normal ruby objects, which are much easier to operate on.

The Ruby AST is decorated with a lot of information concerning node position, effects on other nodes, etc. This information is used in the next phase, which uses the visitor pattern to flow downward from the root of the AST into its leaves. This is the bytecode generation phase.

Each node is responsible for generating bytecode for its representation, which it does by calling methods on a generator object. This has many advantages. It's trivial to pass down a special test generator, which  keeps track of all of the calls it receives for later comparison with the results of another test generator. This is how we test the compiler's bytecode generation.

At this stage, a bytecode generation object has called all these methods, and that object has retained the information in a simple list. The list contains the name of the bytecode to emit and its operands (the arguments to a bytecode). This information contains an additional level of indirection to make generation easier, such as the use of goto targets as normal Label objects.

Because an InstructionSequence must be a list of Fixnums, these Label objects are resolved into bytecode locations, a simple offset from the beginning of the method. An InstructionSequence represents the full bytecode for a method as Tuple of Fixnums.

And so after all those transforms and operations, we've turned

def foo(a,b)
  a + b
end

into

#<Rubinius::Tuple: 19, 0, 19, 1, 77, 0, 12>

or, rendered symbolically:

[[:push_local, 0], [:push_local, 1], [:meta_send_op_plus, 0], [:ret]]

It should be noted that because Rubinius uses normal Ruby objects for as much as possible, it's trivial to see this information for yourself. Here's my irb session to extract the previous values:

>> cm = def foo(a,b); a + b; end
=> #<Rubinius::CompiledMethod foo file=(irb)>
>> i = cm.iseq
=> #<InstructionSequence:0x142>
>> i.decode
=> [[:push_local, 0], [:push_local, 1], [:meta_send_op_plus, 0], [:ret]]
>> i.opcodes
=> #<Rubinius::Tuple: 19, 0, 19, 1, 77, 0, 12>

You can also get a more assembly-oriented view:

>> cm = def foo(a,b); a + b; end
=> #<Rubinius::CompiledMethod foo file=(irb)>
>> puts cm.decode
0000:  push_local                 0    # a
0002:  push_local                 1    # b
0004:  meta_send_op_plus          :+
0006:  ret
=> nil

So we've now got this list of Fixnums, but we're missing one part of the equation. A list of Fixnums is data poor—you can't represent much using that. So associated with each InstructionSequence within the CompiledMethod is a Tuple called the literals Tuple. It holds objects that can be directly referenced by the bytecode.

The simplest example of this is the :meta_send_op_plus opcode we see above. That 0 on the end says "the name of the method to send is located at position 0 in the literals Tuple." Lets take a look at the literals Tuple for this method:

>> cm.literals
=> #<Rubinius::Tuple: :+>

There we go. One entry for the symbol :+. Let's look at one more example:

>> cm = def foo(a); p a, "hello evan"; end
=> #<Rubinius::CompiledMethod foo file=(irb)>
>> cm.iseq.decode
=> [[:push_self], [:push_local, 0], [:push_literal, 0], [:string_dup],
[:allow_private], [:send_stack, 1, 2], [:ret]]
>> cm.literals
=> #<Rubinius::Tuple: "hello evan", :p>
>> puts cm.decode
0000:  push_self
0001:  push_local                 0    # a
0003:  push_literal               "hello evan"
0005:  string_dup
0006:  allow_private
0007:  send_stack                 :p, 2
0010:  ret
=> nil

In this method, we see two literals being referenced. The string "hello evan" is used pushed onto the stack by the :push_literal directly, and the :send_stack instruction indicates that position 1 contains the method to send. In this case, it's :p.

So there you have it: we've taken the text of a program and turned into a set of Ruby objects that the Rubinius VM can execute. In a later post, I'll cover how the VM interprets the bytecode to run the method, and we'll cover compiling this bytecode down to machine code that can be directly executed by the CPU.

We're hard at work, but always looking for new contributors and community members. If you like what you see, find us on IRC or leave a comment!

Here is what was done:

* The old master branch was renamed shotgun.
* The cpp branch was copied to the name master.
* The cpp branch was then deleted.

Anyone that has up to now been working on the cpp branch has a couple of options.

# Delete your clone and re-clone. This is the easiest. The default checkout will be code in the cpp branch and you're off and going.
# Fix up your current repo. I did this by doing the following commands:
** git checkout master
** git reset --hard origin/master
** git branch -d cpp
# This will get your local master branch repointed and properly checked out. In addition, the old cpp local branch can be deleted.

Hopefully no one experiences much pain due to this change. It's been a long time coming and I'm really excited.

If you do run into problems, post a comment or stop on by IRC and we'll work it out for you.