<p>Oldmoe: Hello Koichi, let&rsquo;s start by asking what are you planning for Ruby 1.9.2?<br />Koichi: I am mostly interested in the core. Optimization, debugging and profiling support. We are now trying to define the API to expose the internal structure. They were open in 1.8 but we had to close them and we need to expose C level API functions. I am mostly interested in cleanly exposing the internal structure for a tracing API. If we conclude the design soon it will make it to 1.9.2.<br />Oldmoe: A tracing API for use in a tracing optimizer?<br />Koichi: Well, the new tracing API is mainly geared towards debugging and profiling rather than optimization at this stage. Ultimately we want to build an optimizing JIT.<br />Oldmoe: And what about RICSIN? Will it come to 1.9.2?<br />Koichi: I want to move C extensions to RICSIN. Which is more efficient because RICSIN calls C methods directly. It might not be included in 1.9.2 due to time constraints. Though I can sneak it in via a single instruction modification to the VM without other committers noticing, except Matz, I will probably do that!<br />Oldmoe: What is the current state of GC optimizations?<br />Koichi: It is hard to implement a generational garbage collection of the current MRI. Mostly because of write barrier issues. Author Nari is experimenting with a semi generational garbage collection that stores nodes in a different heap. This leads to the GC not checking for code very often. But currently we store inline cache in specially managed heaps by the VM and we do not expose them to the GC thus making this part more efficient. We will most likely use that and roll back the semi generational garbage collector.<br />Oldmoe: Matz mentioned that Ruby is being funded for use in HPC, how will the VM adapt?<br />Koichi: Yes, currently Ruby has received funding to improve its use in HPC. These guys usually use Fortran and we hope to reach a state for the first 5 years which will enable Ruby to be viable in the HPC area at least for effective prototyping. This is mostly an academic effort so we will need to publish many papers. We need to balance the academic efforts with providing practical implementations.<br />Oldmoe: What about the current status of the fiber implementation?<br />Koichi: Using getcontext/setcontext should help fibers be much faster. It should help some clever library writers to use it. If someone has idea to improve fiber features please tell us. We basically wrote the fibers for enumerators but not for scalable I/O. Seeing them used for scalable I/O is interesting.<br />Oldmoe: What about Multi Virtual Machines (MVM)?<br />Koichi: My goal of MVM is to find an efficient way to communicate between several VMs in the same process. This should also enable parallel computing in a single process for CRuby. It is currently lagging the current trunk. It needs some work to enable it to use C extensions.<br />Oldmoe: What about a multi process approach to MVM?<br />Koichi: We are not considering it right now. But ultimately we want the API to seal the actual implementation which might decide to fork a new process or a new thread or even start a new process on a new machine across the network.<br />Oldmoe: What are your plans for the future of the Ruby VM?<br />Koichi:&nbsp; I believe some compilation can be done. Either JIT or AOT compilation. I am considering a tracing optimizer. It should enable Ruby to gain optimizations like those that happened for Firefox and Safari Javascript engines. Ultimately we don&rsquo;t want to hand code a very complex VM. Whenever we can automate the optimizations it will be better as we need to keep the core of the VM very simple.<br />Oldmoe: What about facilities for writing optimizers in Ruby?<br />Koichi: I have made a proposal to Matz to provide a to_s method to procs but we are still considering it. This should provide the ability of doing runtime optimizations in Ruby. I would say that we want to have more clever ideas to improve performance without sacrificing the dynamic features of Ruby.<br />Oldmoe: Thank you Koichi for your time.</p> 2009-08-30T03:30:36Z http://railsmagazine.com/forums/2/topics/76 48 4 12 2009-12-24T20:55:24Z