Upcoming MacRuby implementation to be substantially faster

Benchmarks of the experimental branch of the MacRuby implementation suggest …

If you're a Mac OS X programmer who wants to write Cocoa applications using Ruby, your options are somewhat limited. The RubyCocoa framework allows users to work with Objective-C objects and write Cocoa applications, but the framework suffers from some performance issues.

In order to provide an easier way to write Cocoa applications in Ruby, Apple engineers have been working on a replacement for RubyCocoa called MacRuby. The MacRuby project released a new stable version last week, and is now turning its attention to the next release, the "experimental" branch. According to Zen and the Art of Programming, the future MacRuby 0.5 release is something that Ruby programmers should keep an eye on, since it looks to be substantially faster than the current OS X implementation of Ruby.

So just what is MacRuby, and why is it so fast? Basically, MacRuby takes the current OS X implementation of Ruby, which is based on the Ruby MRI reference implementation, and ports it so that it makes greater use of the Objective-C runtime. The goal of the project is "seamless integration" with Objective-C.

In practice, the modifications mean that Ruby classes and objects are actually Objective-C classes and objects, making it very easy to write Cocoa applications. MacRuby's combination of Ruby and Objective-C also allows it to use Core Foundation and the Objective-C garbage collector. MacRuby also includes a framework called HotCocoa that provides and easier way to interact with the Cocoa API using Ruby code.

One of the other benefits of mixing Ruby and Objective-C is that it speeds things up, which is the goal of the next MacRuby release. A new compiler (LLVM) is being added to the implementation and the MacRuby team is working on the IO system.

Zen and the Art of Programming ran a few benchmarks comparing the MacRuby experimental branch to the existing Ruby implementation, and MacRuby turned out to be an average of three times faster.

Of course, the experimental branch is still in development and may trade some of its speed for compatibility with the Ruby specification, but even so, the upcoming release of MacRuby should be a big improvement for Ruby programmers who use OS X.

5 Reader Comments

The rubinius project jumped on board the LLVM train about a year ago and abandoned it a few months back. That project also showed some really nice performance improvements, but the main developer jettisoned LLVM due to the high "toll cost" of the LLVM JIT API (whew!).

Also, MacRuby fails a good chunk of the rubyspecs now. As it is brought back into compliance, its performance will drop. I'm passing this opinion on from the leads of both the rubinius and jruby projects who have been down this road a few times before.

That said, I am extremely excited to see MacRuby getting so much attention from Apple. While I don't dislike objective-c, I have a vast preference for the ruby syntax. I played a bit with it after the 0.3 release and found the HotRuby extensions to be fantastic in reducing code clutter. Between this and Atlas (objective-j, browser-based xcode and ib) this is a really exciting time to be on the Mac side.

The important thing about MacRuby (and its primary purpose) is to be a faster RubyCocoa and, while I don't have stats to hand, it should blow the old way out of the water. This is because the old way had to switch between Ruby and Obj-C and the new way is both at the same time.

If it's also a faster Ruby then that's just frosting. After all, there's nothing stopping Apple shipping any other ruby version they want to in addition for standard ruby tasks.

Another point is that it is highly unlikely that Apple which ditch LLVM, or have it be high "toll cost". Apple has invested a great deal of effort with LLVM in the guise of clang, the iphone, and opengl. If anything it looks like Apple is positioning LLVM as core component of their foundation.

There seems to be a shift from bridges such as RubyCocoa or PyObjC to native languages directly built on top of Objective-C, such as MacRuby. Performance is better and the impedance mismatch is greatly reduced, which is even more interesting IMO. AFAIK, there are two other “native” Cocoa languages: F-Script (Smalltalk) and Nu (Lisp/Ruby). Both of them are worth looking at. F-Script comes with a GUI for introspecting Cocoa objects, which is useful even if you don’t program using the F-Script language itself. Another cool thing is that it can be dynamically injected into any Cocoa application.

While I don't dislike objective-c, I have a vast preference for the ruby syntax.

To each his own, I guess. I played around with Ruby a few years ago. The one thing I liked about it was the ability to extend a class through modules. In every other respect, I consider it a significant backslide from the power and simplicity of Smalltalk. The syntax is very clean and very easy to read, far more so than Ruby, IMHO.

Never programmed in Objective-C for Mac, but I was an engineer at the company that developed Objective-C (PPI then became Stepstone). NeXT was one of our customers. The nicest thing about Objective-C is the message passing expression inherited from Smalltalk, though the later introduction of interfaces was a not-very-Smalltalk-like nice addition.

quote:

AFAIK, there are two other “native” Cocoa languages: F-Script (Smalltalk) and Nu (Lisp/Ruby).

I'll have to check F-Script out. I always thought it was a mistake that AppleScript went in the direction of HyperTalk syntax instead of Smalltalk. Very ironic, since the leader of that effort was Kurt Piersol. Kurt was a legend in the Smalltalk-80 community when he worked at Xerox Special Information Systems.