Topaz Ruby

Talks

Topaz Ruby

Tim Felgentreff

#programming-language

#python

#compiler-design

Topaz Ruby

by Tim Felgentreff

The video titled 'Topaz Ruby' features Tim Felgentreff discussing Topaz, a new Ruby interpreter that he and Alex Gainer have been developing. Key points of the talk include:

Introduction to Topaz: Tim introduces Topaz as a Ruby interpreter built using RPython, which compiles Ruby into a custom bytecode set. The project was revealed six weeks prior to the talk and aims to explore whether RPython could effectively handle Ruby.
RPython Advantages: Tim explains that RPython allows for translation into C, enabling the creation of a fast binary interpreter. This implementation benefits from a Just-In-Time (JIT) compiler similar to the JIT for PyPy, allowing for efficient execution of Ruby code.
Unique Ruby VM: He clarifies that Topaz is solely a Ruby VM and does not serve as a bridge between Ruby and Python, dispelling any confusion regarding its functionality in relation to PyPy.
Motivation and Background: The motivation behind creating Topaz stems from a desire to enjoy the process of programming and to investigate the capabilities of RPython. Tim shares his journey of how he became involved in the Topaz project after discussions about PyPy and its applications.
Current Development Status: The project has successfully passed approximately 5,000 Ruby specs, although it still has a long way to go compared to other Ruby implementations, which have tens of thousands of specs.
Performance Benchmarks: Tim conducts a benchmark comparison with JRuby, showcasing Topaz's performance in executing Ruby code, demonstrating that Topaz can run certain benchmarks significantly faster than JRuby.
JIT Execution Insights: The talk includes insights into how the JIT works in Topaz, highlighting its ability to optimize Ruby operations dynamically during runtime.
Community Engagement: Tim invites contributions from the Ruby community, encouraging collaboration and interaction through the Topaz project’s channels and showcasing the importance of community support for the project's growth.

The main takeaway from the presentation is that Topaz aims to be one of the fastest Ruby implementations by leveraging RPython's capabilities, and it invites developers interested in Ruby VM development to participate in its journey toward improved performance and feature implementation.

00:00:18.600 Please welcome Tim.

00:00:26.840 Hi, okay. This talk is going to be about Topaz, which is a pretty new Ruby implementation. I've been working on it with Alex Gainer for the last eleven months or so, but we revealed it six weeks ago.

00:00:33.480 You may or may not know what it is, or you may not clearly understand why we created it. Maybe you've already played with it or even contributed. Regardless, I'm just going to tell you what it is anyway, and if you already know, that's good.

00:00:41.120 So, Topaz is first and foremost a Ruby interpreter. It has a custom bytecode set that it interprets, and it is pretty standard parsing of Ruby, compiling Ruby into bytecodes and interpreting those. That's fine; that's easy, and everybody does that, right?

00:00:55.399 Now, the first interesting thing is that it's written in RPython. This kind of resembles Python but isn't quite Python. I'll get to that later. So, we have this interpreter that's written in a kind of Python, and the cool thing about this kind of Python is that you can translate it into C and then compile it. What that gives you is a pretty fast binary that does a good job at running Ruby.

00:01:08.840 That's awesome! The really cool thing about RPython is that it is actually the implementation language that powers the PyPy Python implementation. If you've ever done Python programming, you may know that PyPy has a very good JIT (Just-In-Time compiler), and we inherit this for free.

00:01:22.600 Now, this JIT isn't actually the same as the one for PyPy, because PyPy doesn't have just this one JIT. You can implement other languages on top of Python and reuse the JIT. When you translate an interpreter into C using RPython, it can actually generate a JIT specifically for your language. It's capable of doing a great job at accelerating exactly your language.

00:01:35.800 So, Ruby code like this, where we run a loop, may be represented in Python code that does a bunch of work trying to figure out what kind of classes we're dealing with. You can already run this Python code on a Python virtual machine and effectively have a real Ruby running on top of a full Python VM.

00:01:53.560 You can translate this to C, but it gets quite lengthy, and I couldn't fit the entire code for this on the screen. This is just the first part of the declarations. However, it also generates JIT information for that method.

00:02:07.560 So, when executing that Ruby code, the Topaz VM will eventually decide, 'Hey, I'm going to trace what you're doing here.' It will realize that you're running this method multiple times, and therefore it will see, 'Oh great! I already have some information about how to speed this up and generate machine code for this.' And it will do that, boosting your Ruby code instantly.

00:02:28.200 There has been a lot of confusion regarding this. While Topaz is written in RPython and while RPython also powers PyPy, it is not a VM that runs both Ruby and Python. There's been confusion on Twitter about whether we suddenly have a VM where Ruby runs on top of Python or if we can mix both languages. That's not the case; it's just a Ruby VM.

00:02:49.680 You might wonder, 'Why another Ruby VM?' We already have so many VMs, and projects like JRuby and Rubinius have taken years to become usable. Why create a new VM?

00:03:01.000 The reason to write a new VM is simply that it's fun and we wanted to explore whether RPython could handle it. Before Topaz, I had never worked on a Python project. I enjoy coding in Ruby and Smalltalk, but Python hasn't been my thing.

00:03:19.080 So, how did I get involved? Eleven months ago, I spoke with K. Fred Boltz, who had just finished his PhD on some metatracing JIT optimizations they do in PyPy. He mentioned that PyPy is a great language for writing interpreters, so I tried it out and wrote a little functional language.

00:03:37.759 I found that it was really easy and quick, and it was already quite fast due to its JIT generation. That's when I thought Ruby could greatly benefit from this technology. I asked Fred if anyone was working on Ruby with PyPy and found out that Alex had committed the first code to Topaz just two weeks earlier.

00:03:53.000 That's how I ended up on the project. As I mentioned earlier, RPython isn't really Python, so I'm technically still not working on a major Python project. I'm still not officially using Python.

00:04:11.480 The reason is that RPython is a restricted subset of Python that is amendable to static analysis, which is necessary if we want to transform it into a language that can be statically compiled, like C. Since RPython isn't clearly defined, the RPython translation toolchain analyzes your entire program: every potential path it might take, and it decides if it can prove enough about the program to convert it to C.

00:04:29.679 This makes it very hard for anyone to tell whether a program is RPython or not, or which parts aren't RPython until you actually try to translate it. In practice, this means that most of the Python standard library is off-limits for you, since it's too dynamic to be analyzed and compiled down to C.

00:04:52.560 I see RPython as a language that looks like Python but serves as a tool for writing interpreters, helping with that process. If you're interested in contributing to Topaz, here's a quick overview of its current structure.

00:05:08.760 There's nothing really exciting like any other interpreter. You have an object space that starts by creating your nil object and true, false, and all these core objects. You also have core classes that are created before running any Ruby code, along with the lexer, parser, compiler, and a bytecode interpreter.

00:05:25.920 One of the areas I plan to expand is the part of Topaz that's already written in Ruby. We found that Topaz does such a good job at optimizing Ruby code that we can write large portions of the core library in Ruby.

00:05:38.919 You might have heard similar claims about the Rubinius project, and we're still at a very early stage. We may eventually find that we have to shift code from Ruby to Python or vice versa. However, we're in a unique position where some code performs faster when implemented in Ruby than if it were in RPython and compiled to C.

00:05:56.840 To summarize our current status: when I prepared these slides a week ago, we had passed around 5,000 Ruby specs, mostly core specs. If you're familiar with the Ruby spec project, those include core, command line, library, and language specs. Of the 5,000 expectations we passed, most are from core and a few from language.

00:06:10.400 The reason we haven't copied the Ruby standard library into our repository yet is that we don't run those specs. Even in core, we're still missing many methods and corner cases. However, the Ruby spec has been extremely helpful in getting us up and running.

00:06:24.160 So, running 5,000 Ruby specs isn't much. For comparison, Rubinius passes about 150,000 expectations. I'm bringing this up to state that we're really fast. You may have heard similar claims from the JRuby and Rubinius teams.

00:06:37.320 What we did was check back with Evan and others from Rubinius and JRuby to find out the hardest problems when implementing Ruby. Those problems typically slow down the implementation. For instance, capturing full binding to execute a binding eval or running an eval in a block context can be expensive for some implementations.

00:06:49.920 We implemented capturing binding with minimal performance impact. The set_trace_func is another feature that can be quite costly. In JRuby, object space isn't even activated by default.

00:07:04.520 We ensured that we implement these Ruby features effectively while still maintaining high speed. However, for proper benchmarks, we still have so much left to cover.

00:07:22.880 We're lacking encoding support, meaning any benchmarks that run on Topaz, especially those involving strings, may skew in our favor since we don't have encoding checking or conversion.

00:07:37.440 As for threads, there's a branch in RPython that might help us add native thread support. However, at this point, we're uncertain about how to do that effectively.

00:07:50.530 Currently, the source tree contains about 15,000 lines of Python and 2,500 lines of Ruby. This should give you a general feel for the size of the project, and I was surprised to find that we have such a notable amount of Ruby compared to Python.

00:08:08.480 Now, I'm going to switch over to demo mode. First, I'm going to run this simple benchmark, which is essentially a while loop and some modulus operations.

00:08:24.400 This will be run on JRuby first, as it is the fastest other implementation I could find. This benchmark takes about four seconds.

00:08:34.360 This specific kind of Ruby code is not something I would typically write. I prefer using 'each' for iteration.

00:08:48.080 Let's see how Topaz performs on this benchmark. I know this may not work because I've reserved some time in this talk to show you how I would implement a method like 'fix_num_div_mod' in Topaz.

00:09:09.960 So the first thing I'll do is figure out where 'div_mod' is implemented. I found 'BigDecimal C Numeric div_mod'. It just returns an array of the quotient and the modulus.

00:09:22.200 So, I have to implement this for 'Numeric'. It turns out that Python already has a built-in function for 'div_mod', so I’ll try and use that.

00:09:38.479 Before I implement it, I could first check that it behaves the same as in Ruby, which it does.

00:09:51.040 While I'm implementing this in RPython, if you clone the Git repository for Topaz, you will notice that the structure contains plenty of less important temporary files.

00:10:04.480 To find class implementations, head to the 'objects' directory. We used to call things 'Fixnums' but changed it to 'Integers' because we hadn’t done the hierarchy properly yet.

00:10:20.760 The implementation for the Fixnum Ruby class is housed within this Python class. It inherits from a Python object.

00:10:36.080 However, on the Ruby side, it looks like Fixnum inherits from Integer, as you may know, while we can have different hierarchies on the Python side for efficiency.

00:10:50.360 Now, let’s take a look at how to implement 'div_mod'. Every Python implementation of a Ruby method takes self as the first argument and typically another argument.

00:11:06.200 This includes the decorator that exposes the method as 'div_mod'. It also incorporates some conveniences for automatic type casting, allowing us to expect 'other' to be an integer.

00:11:22.799 This ensures that whenever the method is called from Ruby, it sends the first argument through this `int` method automatically.

00:11:37.840 Now we can create a Python integer object based on the integer value. However, we want to return a Ruby Integer object.

00:11:49.640 To accomplish this, we'll need to wrap the output of our Python tuple within a Ruby array.

00:12:02.160 You will notice that many operations go through 'object space', which serves as a primary space for referencing objects in Topaz.

00:12:19.920 Let's go back to the benchmark.

00:12:28.200 Because I'm running this in interpreted mode, I may have to exit early.

00:12:39.520 Earlier, I mentioned that you can run the entire Python code on a Python VM. It will be slow, but it's great for testing.

00:12:54.440 Now, let's see if it returns the same result as Ruby. The inspect string is incorrect, but we’ll say that’s acceptable for now.

00:13:05.760 In Ruby, users can pass more than just fixnums; they can also pass bignums, floats, and even infinity. So, I’ll implement this in Ruby instead.

00:13:16.480 This Ruby implementation correctly handles all the intricacies of its behavior. The advantage of implementing in Ruby rather than Python is that you avoid the lengthy analysis and conversion process.

00:13:31.080 Instead, you just write and add the Ruby code directly, which integrates nicely with the compiled version of Topaz.

00:13:46.919 Now let’s re-run the benchmark. While JRuby took about four seconds for a specific case, we're seeing much faster times.

00:14:01.760 The key takeaway is that we’re faster. More importantly, Ruby code is not slower than the Java code.

00:14:12.360 Let's take a glance at how the JIT functions. I'll generate a log by setting the PIP_LOG environment variable.

00:14:26.840 When I run Topaz again, it'll produce this log, capturing various operations and their statistics.

00:14:48.120 In this JIT execution, we can observe that in every loop, it's assessing a local variable's state. Post-JIT, it checks whether this local variable remains an integer.

00:15:06.760 The JIT can optimize the condition checks, leading to lesser overhead as the process becomes more straightforward.

00:15:21.920 The optimization sheds unnecessary operations as it identifies that we aren't interacting with certain elements, like the block, allowing for direct execution.

00:15:37.240 The JIT generates very efficient integer operations to streamline processes, resulting in performance advantages in this instance.

00:15:52.080 This quick overview shows how Topaz can deliver significant improvements to Ruby performance.

00:16:06.240 From this presentation, you've learned that we strive to be the fastest Ruby implementation. Even as we implement more features and size up against Rails, we aim to maintain this speed.

00:16:14.760 However, we will need help to prove that Topaz is indeed faster compared to other Ruby versions. If you're interested in Ruby VM development or if you encounter issues, please consider contributing.

00:16:30.560 We encourage you to engage with our community on the Topaz Freenode channel and follow the Topaz project for updates. Here are the links to the git repository and the website.

00:16:51.680 My Twitter account and IRC name are listed here, so feel free to reach out if you want to discuss Topaz further.

00:17:06.800 Thank you.

00:17:11.400 Thank you very much! Any questions? We have two more minutes.

00:17:21.639 It seems like Rubinius might be a good source of code for Topaz. What do you think about the time and effort it might take to port code from Rubinius over?

00:17:43.680 The core source code in the kernel has three subdirectories: core, common, and delta. Initially, the idea was to share code with Rubinius by avoiding Ruby-specific code.

00:18:03.680 When examining Rubinius primitives, you'll notice many files still contain Rubinius-specific code. We will copy the necessary files over to be functional.

00:18:20.480 Having discussions with the Rubinius team shows they're still interested in sharing code, which we see as an opportunity for collaboration.

00:18:36.640 Regarding benchmarks, I would not recommend using wall-clock time comparisons for performance measurement in a JIT VM.

00:18:48.600 I believe Topaz will be the fastest Ruby implementation as a Ruby programmer. However, I'd advise using operations per second instead, which allows for better warm-up of VMs.

00:19:04.000 How does Topaz perform over time, especially when dealing with varying request patterns on large applications?

00:19:13.000 The JIT never stops monitoring execution. If you run a million loops and experience a pattern change, it will continue optimizing new operations.

00:19:25.280 Could you revert to the slide showcasing the hard problems faced? It appears many of these challenges are universal among Ruby implementations.

00:19:36.480 Indeed, solving these isn't just difficult for Topaz but for any Ruby implementations aiming to be performant.

00:19:57.520 Finding balance between a foreign function interface and retaining speed can be tricky. JRuby has deprecated C extension interfaces due to performance challenges.

00:20:14.250 Asking Ruby developers to rewrite their C extensions for Topaz is quite a tall order. That idea was at the core of Ruby's FFI, but it remains tricky.

00:20:31.760 What has been the most valuable takeaway from working on Topaz?

00:20:47.600 I learned to trust the power of metatracing.

00:21:04.240 Many have shared that MRI has hard-to-understand documentation. Did you face challenges that led you to read source code to comprehend certain behaviors?

00:21:13.600 Yes, indeed. Many aspects of MRI are poorly documented, and its source can be quite hard to navigate. However, I found Rubinius's code very well documented, clarifying many behaviors.

00:21:29.680 I heavily relied on work done by the Rubinius team, especially regarding Ruby spec.

00:21:46.560 Is Topaz aiming to remain relevant to Ruby 1.9 or 1.8 features, or is the focus solidly on 2.0?

00:21:59.640 For the time being, we're concentrating on 1.9.

00:22:08.480 One last comment about benchmarks: I found the example benchmark somewhat too artificial.

00:22:22.760 Optimizers in compilers often conduct computations at compile time, leading to misleading metrics. A different benchmark approach could yield varied results.

00:22:37.600 I'd like to see benchmarks that utilize diverse input to gauge accuracy under realistic conditions. However, I did experience instances where PyPy lost to Python depending on the scenario.

00:22:52.000 To clarify, the previous benchmark wasn't designed to be comprehensive. It was too simplistic. I simply wanted to keep it brief for the talk while demonstrating the jit log.

00:23:05.680 Nevertheless, there's a benchmark suite called 'Meta Tracing VM Experiment' on GitHub, created by Lawrence Tratt, which involves extensive benchmarks using external input. I'm attempting to run these benchmarks on Topaz.

00:23:23.680 So far, any that currently execute on Topaz outperform JRuby, with the exception of a simplistic Fibonacci example.

00:23:40.960 I aim to ensure all these run effectively and efficiently on our Ruby implementation.

00:23:54.080 Thank you for your questions.

wroc_love.rb 2013