For the past three years, I’ve been participating in adding just-in-time compilation (JIT) to CRuby. Now, CRuby has the method-based just-in-time compiler (MJIT), which improves performance for non-input/output-bound programs.
The most popular approach to implementing a JIT is to use LLVM or GCC JIT interfaces, like ORC or LibGCCJIT. GCC and LLVM developers spend huge effort to implement the optimizations reliably, effectively, and to work on a lot of targets. Using LLVM or GCC to implement JIT, we can just utilize these optimizations for free. Using the existing compilers was the only way to get JIT for CRuby in the short time before the Ruby 3.0 release, which has the goal of improving CRuby performance by three times.
So, CRuby MJIT utilizes GCC or LLVM, but what is unique about this JIT?
Continue reading “MIR: A lightweight JIT compiler project”
Red Hat Software Collections supply the latest, stable versions of development tools for Red Hat Enterprise Linux via two release trains per year. As part of the latest Software Collections 3.3 release, we are pleased to share that Ruby 2.6 is now generally available and supported on Red Hat Enterprise Linux 7.
Continue reading “Ruby 2.6 now available on Red Hat Enterprise Linux 7”
Red Hat Software Collections supply the latest, stable versions of development tools for Red Hat Enterprise Linux via two release trains per year. We are pleased to introduce three new and two updated components in this release, Red Hat Software Collections 3.3 Beta.
The new components are:
- Ruby 2.6
- MariaDB 10.3 featuring a new MariaDB Connector for Java
- Redis 5.0
The updated items include:
- Two updates to Apache httpd
- One update to HAProxy
See below for component details.
Continue reading “Red Hat Software Collections 3.3 Beta: New and updated components”
For the last two years, I have been trying to improve CRuby performance. I have been working simultaneously on two major fronts: introducing register transfer language (RTL) for the CRuby virtual machine (VM) and just-in-time (JIT) compilation. For background on the goal of having Ruby 3 be 3 times faster than version 2 (3X3), see my previous article, “Towards the Ruby 3×3 Performance Goal“.
The JIT project (MJIT) is advancing successfully. The JIT approach and engine I proposed and implemented has been adopted by the CRuby community. Takashi Kokubun hardened the code and adapted it to the current CRuby stack machine and recently MJIT became an experimental feature of the CRuby 2.6 release.
Introducing a Register Transfer Language (RTL) to the CRuby VM turned out to be an even harder task than introducing the initial JIT compiler. The required changes to the VM are far more invasive than the ones needed for the JIT compiler.
This article describes the advantages and disadvantages of RTL for CRuby.
Continue reading “Register Transfer Language for CRuby”
You can study source code and manually instrument functions as described in the “Use the dynamic tracing tools, Luke” blog article, but why not make it easier to find key points in the software by adding user-space markers to the application code? User-space markers have been available in Linux for quite some time (since 2009). The inactive user-space markers do not significantly slow down the code. Having them available allows you to get a more accurate picture of what the software is doing internally when unexpected issues occur. The diagnostic instrumentation can be more portable with the user-space markers, because the instrumentation does not need to rely on instrumenting particular function names or lines numbers in source code. The naming of the instrumentation points can also make clearer what event is associated with a particular instrumentation point.
For example, Ruby MRI on Red Hat Enterprise Linux 7 has a number of different instrumentation points made available as a SystemTap tapset. If SystemTap is installed on the system, as described by What is SystemTap and how to use it?, the installed Ruby MRI instrumentation points can be listed with the
stap -L” command shown below. These events show the start and end of various operations in the Ruby runtime, such as the start and end of garbage collection (GC) marking and sweeping.
Continue reading “Making the Operation of Code More Transparent and Obvious with SystemTap”
A common refrain for tracking down issues on computer systems running open source software is “Use the source, Luke.” Reviewing the source code can be helpful in understanding how the code works, but the static view may not give you a complete picture of how things work (or are broken) in the code. The paths taken through code are heavily data dependent. Without knowledge about specific values at key locations in code, you can easily miss what is happening. Dynamic instrumentation tools, such as SystemTap, that trace and instrument the software can help provide a more complete understanding of what the code is actually doing
I have wanted to better understand how the Ruby interpreter works. This is an opportunity to use SystemTap to investigate Ruby MRI internals on Red Hat Enterprise Linux 7. The article What is SystemTap and how to use it? has more information about installing SystemTap. The x86_64 RHEL 7 machine has
ruby-2.0.0648-33.el7_4.x86_64.rpm installed, so the matching
debuginfo RPM is installed to provide SystemTap with information about function parameters and to provide me with human-readable source code. The
debuginfo RPM is installed by running the following command as root:
Continue reading ““Use the dynamic tracing tools, Luke””
This blog post is about my work to improve CRuby performance by introducing new virtual machine instructions and a JIT. It is loosely based on my presentation at RubyKaigi 2017 in Hiroshima, Japan.
As many Ruby people know, the author of Ruby, Yukihiro Matsumoto (Matz), set up a very ambitious goal for performance of CRuby version 3. Version 3 should be 3 times faster than version 2.
Koichi Sasada did a great job improving the performance of CRuby version 2 by about 3 times over version 1, by introducing a byte code virtual machine (VM). So I guess it is symbolic to set up the same goal for CRuby version 3.
Continue reading “Towards The Ruby 3×3 Performance Goal”
Today, we are announcing the general availability of Red Hat Software Collections 2.4, Red Hat’s latest set of open source web development tools, dynamic languages, and databases. We are also announcing Red Hat Developer Toolset 6.1, which helps to streamline application development on Red Hat Enterprise Linux by giving developers access to some of the latest, stable open source C and C++ compilers and complementary development tools.
New language additions to Red Hat Software Collections 2.4 include:
- Nginx 1.10
- Node.js v6
- Ruby 2.4
- Ruby on Rails 5.0
- Scala 2.10
Continue reading “Now available – Red Hat Software Collections 2.4 and Red Hat Developer Toolset 6.1”
In this article, I want to describe how to write a DSL / parser in Ruby with a treetop parser.
Writing the Grammar and Parser in Ruby first has the advantage of interactivity. Ruby is interpreted and has a very quick startup time.
Continue reading “A Beginners Guide to DSL Writing in Ruby”
Hash tables are an important part of dynamic programming languages. They are widely used because of their flexibility, and their performance is important for the overall performance of numerous programs. Ruby is not an exception. In brief, Ruby hash tables provide the following API:
- insert an element with given key if it is not yet on the table or update the element value if it is on the table
- delete an element with given key from the table
- get the value of an element with given key if it is in the table
- the shift operation (remove the earliest element inserted into the table)
- traverse elements in their inclusion order, call a given function and depending on its return value, stop traversing or delete the current element and continue traversing
- get the first N or all keys or values of elements in the table as an array
- copy the table
- clear the table
Continue reading “Towards Faster Ruby Hash Tables”