Chromatic,
A tracing & optimizing JIT that is Perl-specific, such as what would be created by RPython, should provide some amount of "magical fairy dust" in that it should make Perl 5 run faster. Please correct me on this particular point.
"As fast as C" may be a bit tongue-in-cheek, we can stick with my original phrasing of "within an order of magnitude as fast as optimized C". This should have a very specific meaning to anyone running performance benchmarks. Write some code in C, then write the same code in Perl, then run them for comparison.
I fully agree about the issue of making sure a VM is a suitable target for a particular language.
RPython would generate a Perl-specific JIT. No multi-octopus wrestling match there.
Flavio's Perlito generates Javascript to run in a Javascript VM, but from what little I understand about Javascript it is a high-enough-level language to emulate Perl 5 to some degree. (I've had complex code translated from Perl to Javascript in the past.) Perlito doesn't look like much of a multi-octopus wrestling match between Perl as an input language and the Javascript VM, but I could be wrong.
Ingy's C'Dent and Perl5i are supposed to be generating XS code, so no new VM there, and no multi-octopus wrestling match that I can see.
Reini's B system seems closely tied to the existing Perl 5 interpreter VM, so no multi-octopus wrestling match there, either.
So what am I actually wrong about?
Thanks,
~ Will | [reply] |
Please correct me on this particular point.
Here's a fun one: how do you ensure that the finalization semantics of Perl 5 (thanks to reference counting) are in effect on an RPython platform? How about operator types? Iterator aliasing?
... from what little I understand about Javascript it is a high-enough-level language to emulate Perl 5 to some degree.
Does it support raw memory access, or do things that aren't hashes or floats have to be emulated with hashes and floats?
JIT is only a real advantage when you can use things like type specialization and escape analysis to create straight-line code that can make a lot of assumptions because you've proven them. You have to get the boxing/unboxing semantics right, and you have to have a deep understanding of the memory model of the target and of the hosted language.
(The same laws of physics apply when porting an existing language to a different VM. If you get dramatic speed improvements on all but a few benchmarks, it's a sign that the prior VM was pretty poor, not that JIT magic unicorn-flavored candy.)
| [reply] |