The Ruby+OMR JIT compiler adds a JIT to CRuby. However, it has challenges to surmount before it will provide broad improvement to Ruby applications that aren’t micro-benchmarks. This talk will cover some of those challenges, along with some brainstorming about potential ways to tackle them.
The Ruby+OMR JIT compiler is one way to add JIT compilation to the CRuby interpreter. However, it has a number of challenges to surmount before it will provide broad improvement to Ruby applications that aren’t micro-benchmarks. This talk will cover some of those challenges, along with some brainstorming about potential ways to tackle them.
15. 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/
16. 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
19. 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!
21. 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
27. Make Tradeoffs that are Right for the Ruby Community
JIT Compilation:
Trade startup speed for peak speed.
Trade footprint for speed.
28. What do we prioritize?
Time to First Request?
Time to Peak
Performance?
Peak Performance?
100
64 69
36
25 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.
29. 1. Some CPU intensive applications: OptCarrot
2. 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
33. 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!
34. 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!
35. 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!
?
36. Type Profiling
What types have we seen for this value?
Unlocks:
Speculation and Specialization: Generate code for
the cases we think will happen!
41. 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
45. 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
46. 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...
47. My Personal Ruby Hero
Patched ruby/spec to
allow it to work with
repetition
Great win for JIT testing!
49. 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!
50. 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
52. 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!
53. 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!
55. My To-Do List!
1. Make My Mentorship Commitment Clear!
2. I need to start collecting feedback from ruby-core
on 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.
56. The Audience To-Do List!
1. Give Ruby+OMR a try
2. Open Issues!
3. Ask about helping! Little things are equally
appreciated!
57. My thoughts on hitting 3x3:
57
The Work Ahead!
JIT Work VM Work
The VM Work I
hope can be shared
among competition!
