Why Perl needs a VM

[ben@bpfh.net]

I've got to thinking recently about the issue of whether 
Perl (and dynamic languages in general) need VMs.

I'd been increasingly coming to the conclusion that they do, and
then someone in my team performed a piece of performance analysis
which really made me think.

Our application is a large (currently all-Perl) mail sending pipeline.

Having profiled it, we know that in the critical sending section, the
application is spending most of its time either doing regex or scanning
XML using XPaths.

The former task has Perl showing a minor, but significant performance 
advantage over Java, presumably because so much of the real work is taking
place in optimised C code, down below the runops dispatch.

The latter task is performed in pure Perl, and here Java out-performs by
a large factor (I've heard 20-100x, but I need to dig into those numbers
more - I don't think I want to take them on face value).

I think I'm coming round to the point of view which says that VMs should
be the natural target for dynamic languages because you can then separate
the VM-level optimisation and JITing from the higher-level improvements.

The VM should offer the right sort of hooks to aid dynamic language 
implementors and should be cleanly and publicly specified, so as not to
provide a fast-moving target for anyone trying to target it.

(In terms of our application, I think the writing's on the wall. No-one
wants to start rewriting code for the hell of it, but without something to
boost the XPath performance, at least some of the modules in the pipeline 
will end up being rewritten as Java, because we will need the performance
boost to give us some headroom in the application.)

So, having thrown the hat down, what do you lot reckon?

Ben