evan.musing << current

Too long since the last posts, I need to figure out how to make sure I do at least one post a week.

Anyway, since last time, rubinius has evolved more is really beginning to grow into it’s own. The denizens of #rubinius have been working hard, building up the core library. In the meantime, I’ve continued to work on the VM backend.

Performance

I’ve made a number of performance changes in the last month. The first was speeding up how stack frames (MethodContext) were created. They’re now opaque objects so that the VM can manipulate them much more quickly. There is still some work to do in that department as well, mainly in cache contexts rather than just throwing them away everytime.

Next, I went through and made a bunch of changes to how the C code is generated by tweaking the GCC options. That alone sped the VM up by about 200%. GCC now properly inlines the critical VM sections, which is a big boost.

I also added 2 method selector caches. MSC’s speed up method dispatch a lot because they save you have having to traverse all around any number of classes to find the proper method to call. The first cache is a global cache like 1.8 sports currently. It boosted performance by another 100% probably. I’ve now begun experimenting with inline caching. Inline caches stash the last method that was called at a call site so it can be used again. I’ve implemented inline caches for both method calling and access of constants. The inline caches are currently make a small performance improvement over the global cache, but I need to write some good benchmarks to get some decent numbers for comparison.

My current task is to get the interface for calling back into C code finished and commited. It’s going well and is going to use C/Invoke to speed up calling these functions. I’m particularly proud of the design, it’s going to allow the VM to remain stackless (ie, doesn’t use C stack to call methods) yet the C code can call back into ruby code.

Lastly, i’ve created a tumblr. Check it out!