One of the most visible presentations from last weeks RailsConf was Avi Bryant’s demonstration of MagLev, which is a RubyVM that is based on Gemstone’s S/64 VM for Smalltalk. This caused a stir because the micro benchmark performance of MagLev looks really good because S/64 has been out in production for a while and because it appears to have some really interesting features (an OODB, shared VM’s, etc). MagLev is a reminder that the world of production quality, high-performance virtual machines is bigger than many of us remember at times.
I believe that over the next few years we will see a flourishing of virtual machines, as well as languages atop existing virtual machines. Take for example Reia, a Ruby/Pythonesque experiment atop Erlang’s BEAM VM. As we return to a multi language world, we will also necessarily return to a multiple implementation world. Before Java, there were many languages and many implementations of those languages. You could argue that there were probably too many, and I think that’s probably true. I would argue that we need to enter a new period of language and runtime experimentation. A big driver, but not the only driver, for this is the approaching multi-core world. When you don’t know how to solve something, more attempts at solutions is better.
“I believe that over the next few years we will see a flourishing of virtual machines, as well as languages atop existing virtual machines.”
In the next few years? That’s what we have been looking at for a while.
Believe it or not, I think we are just getting started.
In this case, Python is in a good starting position with PyPy, which has as one of the primary aims the ability to generate differently configured Python interpreters, targetting multiple VM backends, etc.
Using PyPy it should be easier to make Python run properly on something like MagLev than it would be to really properly port Ruby.
Of course Python doesn’t really need an object database, it already has several, such as the ZODB.
No, I think it’s very clear that software developers can largely ignore dual core systems, because typical background workloads on most machines can utilize about half of the second CPU.
It’s not until you get to 4-core machines that you start to do so at your own peril, and those are just now out there. I would argue that it’s not really until around 6- to 8-cores that things really get uncomfortable for those who refuse to keep up.
I knew I should have left the hardware sentences in that post… Here’s what I mean when I say multicore.
MacPro: 8 cores in the box. Sun x4150: 4-8 cores in the box. Sun T5120 64 hardware threads in the box, T5240 128 hardware threads. All shipping today.
Pingback: Sadek Drobi’s Blog » More languages on top of Erlang virtual machine