At least 50% of this talk Summary comes from Pat Eyler’s excellent notes, which he passed on to me.
Evan is going to spend a lot time explaining Why. Languages are fun and are a good challenge. Why do we a need different interpreter?
Wanted to take the interpreter in a different direction
- simple architecture and core (almost naive)
- as little backend magic (no C objects)
Matz’s Ruby is a huge big Dump truck. YARV is a bright shingy Fireengeine. Rubinius is like a dun buggy. Its fast and light, but your going to get sand in your eyes.
Rubinius has a simple architecture, OK a naive architecture. What does a really simple core and simple architecture mean to a new Ruby interpreter. What does “simple” do for the average ruby or rails programmer?
SIMPLE == POWERFUL for references of simple=powerful see LISP and Smalltalk. Less backend magic means more introspection. We all love introspection. (More introspection means slower runtimes though KBT.)
What does simple do for me
- simple == powerful (see lisp and smalltalk)
- less backend magic == more introspection
- less backend magic == more control
- richer objects (like Backtrace objects or MethodTable objects)
(e.g., backtrace object allows you to look at the Byte Code
being executed — build incredibly rich tools)
Rubinius should make building rich Backtrace and MethodTable objects much easier.
Sydney was a giant patch (12,000 lines) to 1.8.2 which added reentrency, thread safety, and native threads. Sydney was 6 or 7 months of work. It turned out to be a major headache and pain. CRuby uses a huge number of C globals. Had to track down all references to globals and fix them. Sydney was put down, killed.
Sydney was a patch against 1.8.2
reentrant/thread-safe
it hurt (too many C globals)
Sydney died because:
it was too big (12kloc)
OS threading (the killer feature) didn’t really work
Rubinius takes a lot of concepts from Smalltalk. Evan thought, “What if it barrowed even more from Smalltalk?”
Prototype A was a port of the Smalltalk blue book implementation to ruby. It worked but it was slow. Prototype A validated the idea of Rubinius.
New system (Prototype A)
look at smalltalk, and bring even more of it into Ruby
ported the bluebook onto Ruby
worked, but too slow — validated the idea though
Prototype B improved A and does it in a ruby way.
Implemented bytecode interpreter and compiler.
Prototype B
translated Prototype A into Ruby idiom
implemented bytecode interpreter and compiler
Prototype S is a human interpreter which takes prototype B and translates them into C code to get high speed. Prototype S is 10,000 times faster than the terribly inefficient prototype A attempt.
Translater to move Prototype B into C code (like metaruby)
Prototype S
hand translation of Prototype B into C code
moving faster than expected
better than expected
Prototype W is planned to be a automatic translator from B to C code
Prototype W
finish translater for Prototype B
less C to fight with
more accessible
still very much a work in progress
but on the verge of being usable
(KBT Judy is a powerful library of array and hash implementations.)
Discussion
Q: Since I was starting over could I use APR or something to make things easier?
A: yes, using glib (string and pointer array) but trying to use as few external dependecies as possible
Q: Which tests are you you using?
A: Prototype B has 1700 tests in its quite. Prototype S has a rudimentary test suite
Q: How’s performance?
A: too early to tell
Q: Why didn’t you hack with me (Eric)
A: didn’t want to wake you up
Q: So the goal is to write an interpreter in Ruby that translates itself to C?
A: yes I want it to be a community effort, people working on the core and making it better for everyone
Q:Have you figured out how to link to external libs?
A: not yet. I’m hoping that the community can jump in to help
Q: Have you looked at PyPy or others for ideas?
A: Yes, I have … it’s complicated! The complication worries me.
Q: could you generate non-C code? (Use the same Rubinius to create other Rubies)?
A: I hope so, or I’m wasting my time
Q: How am I going to implement native threads?
A: I hope I don’t have to. I hope someone else has already done the work (leverage existing tech)
Q: Why build Ruby2C translator, why bother building the interpreter?
The interpreter is what I want to build the language in and then translate
To get the benefit, I need to translate the Ruby into C
?Just a subset? probably, yes hopeful some charismatic lab will pick it up and create a more complete set of Ruby
Q: It looks like squeak. Have you talked to them?
A: No, I’m afraid they’ll laugh at me (Ryan will introduce me, and they won’t laugh) I’ve looked at them a lot. If I talked to a smalltalk vm person they’d say You’re cheating, you stole our stuff. and I did. I’m trying to stand on as many shoulders as possible
How is performance? Its to early to tell. Prototype S just got working on the flight here.
- Nitty Gritty Parts of Sydney and Rubinius Sydney
- Parser: took matz’s ruby yacc parser, stole from ParseTree and created an extension.
- SegfaultProtection: catches segfaults, turns segfault into an exceptions not available yet, but I want it to be.
- Architecture: is completely component based, explicit APIs, orthogonal chunck, Highly separatable for mix and match.
- Garbage Collectors:
- see the simple two-space baker two-space GC — simple, easy to debug, but a memory hog
- see the train GC — highly efficient for mature objects
- Future directions: non-C backends (java, smalltalk)
More questions
Q: What about the potential for fragmentation?
A: yes, of course I am. I hope that it is as compatible as possible
Q: (YARV compatibility?)
A: not really, I hope that a yrav ByteCode interpreter can be written in Rubinius
Q: How compatible is the ByteCode with Ruby syntax?
A: It’s got low level ops, not really something you can do in Ruby It’s got some high level ops to keep things fast
Q: If JRuby wanted to use this to use build on the JVM could they?
A:Yes. As long as you provide a stable implementation of the two things we rely on ???? and ????
Q: Using Valgrind
A: yes, a little before I got married, look at some futures (valgrind looking for lost Ruby objects)
Q: could I show some examples?
yes, but they’re really boring so I won’t here (off line if you want to see it) Off to a quick sample tests, then implementation files
there used to be an evil.rb that let you set an objects class and things like that, Rubinius has evil built in (Evil to the core)