It doesn’t take long for developers who are using Ruby on a daily basis to start appreciating its simple and elegant syntax. This bundled with the extensive 3rd party tools provided by the open source community and web frameworks like Ruby on Rails made it the language of choice for many startup companies who value developer productivity. Ruby was created in the 1990s and the goal of the creator Yukihiro “Matz” Matsumoto was to create a genuine object-oriented, easy-to-use scripting language. The language steadily gained popularity during the years and it’s considered by many to be in the top 10 most popular programing languages of today.
Since the beginning Ruby was never intended to be the fastest language on the planet and probably never will be. But this hasn’t stopped core developers to improve the performance of the language with every release. Every maintenance release always brings something new in the Ruby world, but the first major performance improvement was introduced in Ruby 2.0 when Koichi Sasada a Ruby core developer did a great job on improving the performance and making it 3 times faster compared to version 1 by introducing a bytecode virtual machine. That same year during the RubyKaigi keynote Matz talked about the challenges for version 3 of the language where he stated that the goal is to make the next major release three times faster compared to version 2.0, and at that moment the Ruby 3×3 initiative was born.
In the past 3 years since that moment Ruby got to version 2.5 and it is realistic to say that the performance has increased by 150% compared to version 2.0 when it comes to real world applications. There were multiple optimization on Array methods, Strings and byte code improvements by removing all trace instructions. But this only got us halfway to the projected goal.
So the next logical step forward was the introduction of Just In Time (JIT) compiler for the language in order to get closer to Matz’s 3×3 vision for Ruby.
Vladimir Makarov a Senior Software Engineer at RedHad who contributed greatly to the performance improvement of Hash tables started the implementation of MJIT (M stand for MRI). In a recent blog post Makarov explained his reasoning about the limitation of the stack based VM and the need to replace it with register based VM in order to achieve a cardinal performance improvement. His early performance benchmarks using OptCarrot (a Nintendo simulator) showed improvements of 283% compared to Ruby version 2.0. He also explained that it will probably take a year to reimplement the virtual machine for CRuby. In the same time Takashi Kokubun started working on a JIT compiler based on the stack machine instructions in order to avoid the rewrite of the VM. Since they both got to almost the same conclusions independently, in order to save time it was proposed to merge the MJIT infrastructure from Makarov with a conservative JIT compiler in early 2.6 releases.
That brings us to the preview release of Ruby 2.6.0 which for the first time included the option to use the JIT compiler. While it is only included in the release to test out the compatibility on different platforms and the current implementation only improves performance slightly, it is the first glimpse of what Ruby future might look like.
Besides the JIT introduction, version 2.6 will also bring speedup of Proc#call and block#call and in generic micro-benchmarks shows a performance increase of 23% compared to version 2.5.1.
While all of this is exciting news for the Ruby community, and we finally get to experiment with a long awaited feature it is unrealistic to expect that we are going to use the JIT compiler for production ready application this year. Ruby version 2.6.0 will be released by the end of 2018 bringing a general improvements in performance for another 5-10%, bringing us pass the halfway mark to Ruby 3×3. This is just another stepping stone closer on the way to a long awaited goal for the language we love, but we are hoping that next year version 2.7 is going to be the last in this release cycle.