Kevin Scott wrote:
> Some of the difficulties they had when using C as the back-end for
> functional languages (like Haskell) were:
Appel has said that ML reclaims about 98% of the heap every time
it collects. Functional languages have such a different model that
it doesn't surprise me that C isn't an optimal fit. For functional
programs a microprocessor's call/return isn't an optimal fit either.
We're talking about Perl here. It's solidly in the procedural camp
with explicit control structures and side-effects up the whazoo.
(Very technical term there. Must have read too much perl6-* tonight.)
> First there's binding time. There are number of Perl features for
> which code can't be generated at compile time, e.g., eval and require.
> How do we deal with these?
We suck in a support library that includes a Perl VM. (BTW a compiler
could honor an eval/require if they appeared in a BEGIN block
and if they didn't have any side-effects that couldn't be reconstructed
by the compiled program. I'm thinking of something like tainting that's
turned on inside BEGIN blocks during compilation.)
> Second there's the issue of portability. Do folks distributing Perl
> software have to generate binaries for every possible Perl target?
> Or do they distribute a high performance binary for the target(s)
> they have access to, and require everyone else to run a slower,
> interpreted version of the same program?
Yep.
Besides the flip-side to the portability coin is the portability of
the Perl language itself. I sure don't want to write the Configure
script for a JIT!
> Just because Kaffe can't get decent performance with a JIT
> compiler doesn't mean that we can't. Kaffe's open source JIT doesn't
> represent the state of the art. Plus Perl != Java.
Yep. I was just trying to bring a little evidence to the table.
Perl has much more complex semantics than Java -- full lexical closures
for one -- that I think would make it *harder* to write a JIT for.
> Many of the reasons for poor JIT performance in Java are related to
> specifics of the Java language
The Kaffe group claims to have more problems with load/store elimination
and inefficient register use. I'm sure scheduling is a problem that they
just haven't discovered yet. This is the type of low-level processor
stuff we'd have to start worrying about.
> Just my $.02 worth.
I'd love to make sure that whatever bytecode format we use can be
easily consumed by a JIT. On those lucky architectures where somebody's
written a JIT, people could use it instead of the bytecode interpreter,
or maybe in conjunction with the interpreter.
It might make sense to partner with Kaffe (I don't know of any other free
JIT implementations). They're GPL though and that would have some
structural impact on everybody to keep perl under the Artistic license.
- Ken
