Matthew Gaudet, February 4th, 2017

Highly Surmountable Challenges in Ruby+OMR JIT Compilation

What’s Ruby+OMR again?

An Open Source Toolkit for Language

Runtime Technologies.

Garbage

Collector

JIT Compiler

Monitoring

Porting Library

…More!

Goal: Compatibility!

Integrate vs. Replace

+

8

Status Update: 13 Months later

10

11

No JIT….

13

14

Today:

Branch ruby_2_4_omr is current default.

– Based of ruby_2_4 tag

JIT Compiler Hooked up and running Travis tests for OS/X and Linux

– Known issues in make test-all

– Passing make test with count=0

Populated and tagged Issue Tracker

Performance: Less specialization to micro benchmarks, means lower

seeming performance.

– Better software engineering

https://github.com/rubyomr-preview/ruby/issues/

JIT integration

Functional Correctness has been primary objective

– Aiming for pass of test suite at all optimization levels.

–No restrictions on native code used by extension modules

Have added some optimizations, but haven’t done much in the way of

tuning.

Simple compilation control

Our Goal:

YES

Be Part of Delivering 3x3

Why?

We think Ruby could really benefit from having a JIT

compiler.

Lots of pre-built JIT compiler technology in OMR, with

potential for exploitation in Ruby.

What’s in it for us? Validation of the OMR approach

–Community improvement: Having multiple consumers

helps us make it better for everyone!

https://twitter.com/ChrisGSeaton/status/811303853488488448

Competition and Collaboration

Having multiple JITs for CRuby could be a really good thing!

Share the load of creating interface and infrastructure that all

JITs for CRuby can rely on.

Competition helps push things forward

Collaboration helps solve hard problems!

21

22 https://twitter.com/ChrisGSeaton/status/811332662350794752

23

Effort!

Re

su

lts!

Community Challenges!

https://twitter.com/tenderlove/status/765288

21993188147226

Make Tradeoffs that are Right for the Ruby Community

JIT Compilation:

Trade startup speed for peak speed.

Trade footprint for speed.

What do we prioritize?

Time to First Request?

Time to Peak

Performance?

Peak Performance?

100

64 69

3625 30 25 26 25 26 25

1 2 3 4 5 6 7 8 9 10 11

Time per Iteration (s)

Prioritization will be driven by benchmarks from the community.

1. Some CPU intensive applications: OptCarrot2. Some memory intensive application: 3. A startup benchmark: time ruby -e “def f; ‘100’; end; puts f”?

4. Some web application framework benchmark(s)?

http://rubykaigi.org/2016/presentations/MattStudies.html

Benchmarks to aim for?

http://engineering.appfolio.com/appfolio-engineering/2016/12/8/benchmarking-rails

Information Challenges

MRI

Garbage Collector

Ruby IL Generator Optimizer

Code Generator

Runtime Code Cache

YARV Interpreter

JIT VM Symbiosis

VMJIT

Performance

Information

JIT ↔ VM Interface

Infrequent Event Notification

Operations such as

Basic Operation Redefinition

Constant Modification

Class Hierarchy changes.

Unlocks:

–More aggressive specialization, class hierarchy

optimization. Don’t create code for things that haven’t

happened yet!

Stack Peeking Notification

A hook that fires when some piece of code wants to look at a

stack frame – Give the JIT compiler a chance to materialize

what it should have looked like.

Unlocks

–On Stack Replacement: Don’t Execute Code for Things

that might happen!

Basic Block Frequencies

How many times has this basic block been executed?

Unlocks:

Better Optimization: Don’t spend time compiling

on things that won’t get executed!

?

Type Profiling

What types have we seen for this value?

Unlocks:

Speculation and Specialization: Generate code for

the cases we think will happen!

Horizon Challenges

Much of MRI’s core functionality is written in C!

A problem for the optimization horizon!

Optimization Horizon Solutions?

Rewrite all of core in Ruby.

‘Lift the Core’

40

Optimization Horizon Solutions?

Incremental Ruby-fication:

More promising… and easy to get started on in Ruby!

Convert prelude.rb to a ‘prelude’ directory, where Ruby implementations

live.

– Startup concerns (parse overheads) – can be mitigated with YARV

bytecode serialization.

– Longer term: JIT AOT Compilation maybe!

41

Optimization Challenges

An admission:

Testing Challenges

JIT Testing is Hard!

Normal Tests

Finish quickly

Coverage with minimal repetition.

Local reasoning / isolation

No special command lines

Compiler Stress Tests

Need to run code multiple times! – Allow the JIT to kick in, profile data

to be collected, and consumed

Potentially require global

reasoning.

Run in multiple VM instances

under different options.

Writing test cases that can effectively stress the JIT compiler is an art

JIT Testing is Hard!

Other problems:

Isolating test cases from each

other

Time accuracy trade off

Coverage

All these problems of JIT

testing will also be equally

true when running a

gem’s test suite with a

JIT...

My Personal Ruby Hero

Patched ruby/spec to

allow it to work with

repetition

Great win for JIT testing!

Engineering Challenges

Keeping up with the firehose?

How do we keep up to date with the Ruby core?

Some is good software engineering… callback generation was

done precisely to address this concern. But more still needed!

The JIT Needs some cleanup

Callback Generator Ruby code isn’t very good!

–https://github.com/rubyomr-preview/ruby/issues/74

Great task for someone good at writing Ruby!

The makefiles need love

– https://github.com/rubyomr-preview/ruby/issues/8

OMR Challenges

OMR is evolving!

We’ve only been open source for 4.5 months!

Still working on improving our interfaces, our

integration story.

Need to build out a community! This is where you

can help!

Mentorship

I’m committed to helping anyone who

wants to contribute to Ruby+OMR

get up and running.

I’ll write documentation for things that are

unclear

I’ll answer email!I’ll help guide

implementationI’ll be on slack!

I’ll schedule a video chat with you!

Ruby+OMR needs community

interest to survive!

My To-Do List!

1. Make My Mentorship Commitment Clear!

2. I need to start collecting feedback from ruby-coreon what we would need to do to get community

members interested.

3. I need to start demonstrating the kinds of VM

changes a JIT will need.

The Audience To-Do List!

1. Give Ruby+OMR a try

2. Open Issues!

3. Ask about helping! Little things are equally

appreciated!

My thoughts on hitting 3x3:

57

The Work Ahead!

JIT Work VM Work

The VM Work I hope can be shared among competition!

Thank you so much!

Acknowledgements

https://en.wikipedia.org/wiki/Foundation_%28engineering%29#/media/File:Concrete_cellar_

10007.JPG

http://emojipedia.org/mozilla/firefox-os-2.5/confused-face/