00:00:07.319
The idea we have here is that each of the implementation teams will get a little bit of time for a quick introduction to their project's status, aims, and perhaps a bit about future plans. Kevin, working on Cardinal, is going to have a longer section, while John Lam, working on Ruby CLR, will have a shorter section because he's also talking again tomorrow. Evan gets a longer segment as well, and then Charles and Tom at the end will have shorter sections since they are also speaking tomorrow. Once they finish their presentations, we'll turn the time over to you to drive questions and get answers from the full panel.
00:00:48.719
So with that said, Kevin, why don't you go first? Okay. For the past two years, I've been following Parrot to some degree, actually quite closely. I've worked on a couple of different projects. The last one I started was Cardinal. Today, Cardinal can perform simple flow control and execute simple functions, but we haven't progressed much beyond that. This is mostly because I’ve diverted my attention to helping Parrot finish up its object system over the past three or four months. Parrot has an object system in place, but it's a bootstrap object system, and we're redoing it. You can imagine implementing Ruby without a proper object system is quite difficult. That’s where Cardinal stands today. I’m very interested in virtual machines and interoperability between languages, which is why my focus is on Cardinal and Parrot, specifically. Parrot has some really exciting features; it has a JIT compiler and good garbage collection ready to go, which need a bit of polishing but are nice to have. It includes an interoperating calling convention, allowing Python, Perl, and Ruby to call back and forth between each other, which is fascinating. Additionally, it has portable bytecode, and we currently run on most common platforms out there, including Intel 64, AMD, and Mac OS X for both Intel and PowerPC. Occasionally, we also have users running on FreeBSD and some SPARC configurations. I'll leave it there for now.
00:02:37.280
I’m John Lam. I spoke with some of you at the last RubyConf about the work I’ve been doing with Ruby CLR. Unlike some of the others here, I can’t claim to be a language implementer—at least not for another few weeks. My primary interests lie in understanding the interoperability problems between dynamic and static languages. One interesting aspect of the Ruby CLR Bridge Project, which I created, is that CLR types and Ruby types can coexist within Ruby programs and look just like each other. I handle all the marshalling, conversions, and interoperability aspects automatically for you, allowing you to navigate this integration smoothly. I even do some quirky things, like mangling the names of CLR methods. The CLR library naming conventions differ significantly from Ruby’s, but I make it possible to call them, keeping your applications look and feel like Ruby while using these methods.
00:03:54.360
This leads to fascinating discussions about dynamic language interoperability issues. If you look at the Common Language Runtime (CLR), similar challenges arise because it was designed from the outset to support multiple static languages interoperating with each other. This includes issues like calling a library written in C from Eiffel or a library written in VB from C. When striving for a common runtime and fundamental infrastructure for all of your other applications, you encounter similar problems. One major advantage of programming on such a platform is that a lot of features, like debugging support, come naturally. If you emit the correct symbol information, you can plug directly into Visual Studio or your favorite debugger and have debugging capabilities along for the ride. These are just some of my initial thoughts on the tough problems within interoperability scenarios, as I'm keen to get comments and feedback regarding these complexities.
00:05:24.840
I'm Evan Phoenix, and I’m sort of the project lead for Reinius, a brand new Ruby virtual machine that we’re building from the ground up. Our aim is to be fully compliant with version 1.8.5, and our big goal is to write as little as possible in C or any foreign language. Essentially, you’ll find that most of the core library for Ruby—all the methods for arrays and such—are implemented directly in Ruby. The VM itself is a slim VM written in C that allows for extensibility, aiming to keep it small and simple while providing a VM that can support a full Ruby implementation on top of it.
00:07:04.320
In terms of goals, we plan to release version 1.0 by October, just in time for RubyConf this year. At that point, it will be 100% compliant with 1.8.5 and capable of running Rails version 1.2.
00:08:38.400
Okay, I'm Charlie Nutter from Sun. I hope everyone here knows what JRuby is by now—Ruby on the JVM. We're progressing with our milestones and details. We will have a talk tomorrow, which is now scheduled to be the finale of the conference. We’re aiming for JRuby 1.0 release in the next couple of months, making it faster than the MRI 1.8.5 release. The last JRuby release we did can run Rails now, and we’ll present more numbers and discussions on that topic tomorrow.
00:09:38.400
I'm Tom Enebo, another developer of JRuby. We will discuss details and answer questions in our talk tomorrow, so I'm more interested in hearing what questions you may have regarding our implementations or concerns about compatibility or what applications we can run.
00:10:54.320
As for questions, ideally, they’ll be broad and relevant to everyone here. If you want to delve into the details of a specific implementation, I would suggest catching one of the implementers during breaks throughout the day. We have Mike Moore circulating with a wireless mic to capture your questions for video and audio.
00:12:07.880
Carl, I want to see if you could comment generally on the performance of your implementations. I’ll start by mentioning that there was a Ruby shootout posted on a blog a few weeks back comparing Ruby 1.8.5 and Ruby 1.9 to the YARV implementation. Cardinal was in there, JRuby was included, as well as Rubinius and Ruby.NET. Overall performance in general cases shows that JRuby is roughly twice as slow as MRI, but as I’ll show in tomorrow’s talk, I have many individual benchmarks that show cases running faster now, even under interpreted mode. When we begin compiling, speeds generally increase significantly compared to regular Ruby, but we still have a lot of work ahead in making the general cases run as efficiently.
00:14:36.360
On the other hand, my goal for JRuby is to achieve runtime optimizations where the JVM can enhance performance. This would mean that if we find a way to optimize the hotspot, it could yield performance that could outperform native C code in numerous scenarios. Regarding the shootout, I was pleased that Rinius was listed there, especially since it passed 60% of the tests. Though it’s still a young project, I had not previously performed any optimization on it, mainly keeping GCC optimizations off to simplify debugging. However, I'd since focused on improving performance by allowing GCC to optimize effectively. Thus far, my benchmarks actually show Rinius surpassing MRI in several cases.
00:16:00.480
For our 1.0 release, I’d ideally like to match MRI performance. Even if it’s mostly as fast as 1.8.5, I think that would still leave significant room for enhancements later due to a simpler and more accessible architecture for optimization.
00:16:38.760
I can comment on IronPython, as it runs on top of the CLR, which is a similar dynamic language. IronPython is recognized as the fastest Python implementation out there due to various benchmarks. Our aim is to continually seek out optimizations and improvements, mostly based on opportunities featuring aspects of the CLR useful for enhancing performance. One of the notable features I’ll elaborate on tomorrow involves dynamic methods. These methods are small chunks of code that you can compile and that are also garbage collectible, which is critical for dynamic languages. This ability allows you to generate multiple short stubs of code that are often rendered invalid and can be discarded over time.
00:20:27.920
To summarize, we have many ways to exploit these features and iteratively optimize our languages as we learn from prior runs. This demonstrates that if you leverage the JIT process well, dynamic languages can compete favorably with C, which is something other VMs can attest to. Similarly, benchmarking comparisons done for Perl against Parrot are frequently showing performance improvements, sometimes two to five times faster than Perl when executing on Parrot. While it can be a mixed bag, the takeaway is that JIT compilation yields significant advantages for performance.
00:21:55.440
Now let’s take some questions. I noticed a few hands raised.
00:22:38.800
If I can recap, someone asked about the language features that are most challenging to implement. One of the easier components has been continuations for us with Reinius due to architecture design factoring all elements as first-class objects. However, it seems that dynamic dispatch presents persistent challenges, as does accurately emulating Ruby's threading model, allowing for numerous illegal operations that can’t safely kill real threads.
00:23:40.480
Another significant difficulty is the handling of `eval`. For those around during the 1.6 to 1.8 transitions, the semantics of `eval` have evolved, introducing special cases that necessitate maintaining the calling environment's integrity. This is crucial as we navigate compiling where we want to avoid unnecessary overhead. In JRuby, we've adopted a mixed-mode engine which interprets some code while compiling others to Java bytecode to find an optimal performance balance.
00:25:30.680
A common challenge we face is the potential for new, esoteric features to arise that require us to rework earlier implementations. Even local variable handling can present significant hurdles, as Ruby allows for a multitude of assignments and syntaxes that may not always be used in practice. Continuations, for instance, have resulted in challenges that leverage the exception mechanism for flow control.
00:27:03.280
The Ruby interpreter, as most languages, follows a deterministic parsing pattern which can lead to ambiguities, especially in distinguishing between local variables and blocks at parse time—an issue we're looking to address in newer implementations. We're modifying our parser to ensure lexically scoped variable handling, eliminating unnecessary legacy complexities and making the implementation cleaner and more efficient.
00:29:15.680
Regarding the Ruby specification, there's been a push for establishing a more formal, community-driven spec—with contributions from various team members. The RubySpec page hosted on a Wiki actively collects information, but there’s still no coordinated effort akin to that utilized by the Python Foundation. Currently, what exists in the wild often becomes the default spec, so our focus remains to integrate this knowledge effectively.
00:30:23.680
There's ongoing interest in creating a common benchmark suite for Ruby, as the benchmarks from the Ruby shootout blog were based on YARV metrics boosting its standing. We anticipate that as each implementation develops its benchmarks, these will converge over time to form a unified Ruby benchmark suite, ensuring continued progress in performance. Early testing conducted through the Fire Brigade tool allows developers to assess gem performance, resulting in improved understanding of how popular libraries perform across implementations.
00:32:05.760
Despite the challenges presented by implementing a formal Ruby spec, the real-time experiences and community knowledge serve as valuable resources for informing the Ruby landscape. Our ongoing dialogues amongst implementers, such as those on compatibility and performance, foster a rich ecosystem that promotes troubleshooting and knowledge sharing.
00:34:02.240
We've only scratched the surface regarding language compilation into C or other outputs. There are numerous challenges due to Ruby's dynamic nature that could severely hinder performance expectations if approached with standard compilation practices. However, we maintain that leveraging the CLR's compiling features allows us to realize optimizations while keeping the essential dynamic functionalities intact. Yes, we've explored concepts for C generation, but the optimizations we can enact at runtime, through JIT techniques, provide a more flexible and beneficial development model.
00:36:29.920
To wrap up, I want to extend my gratitude to everyone for coming out and participating in this engaging discussion on Ruby implementation. We're excited about the future of dynamic language implementations and the potential for increased interoperability across platforms.
