Re: Perl-in-Perl
Reini Urban
<Mariano....@gmail.com> wrote:
> Hi,
> I've been watching PyPy project and the cool things are beginning to emerge
> out of it, such as JIT interpreter, JVM/CLR emitter and other stuff I'm sure
> you're aware of. At the same time the perl5 code base is hard to maintain or
> extend, so I'm wondering how hard it would be to create a similar approach
> of Perl-in-Perl given B::C and PPI exists.
> Since you're the only expert ( or almost ) in the perl optree and the perl
> runtime...
That's not really true. There are many, but I seem the be only one to
have enough and motivation time for it.
> * Do you think it is possible to write PiP?
I think your are referring by the "Python in python" in PyPy to the
RPython interpreter which creates an optimized virtual machine to
execute python.
That is the way perl6 with parrot went, and which most other
functional languages did. E.g. most lisps bootstrap from a limited
"minilisp", then compile their compiler written in lisp and at last
create the optimized executable.
Perl5 does not have this problem, since we already do a lot of good
optimization passes in our core, at compile-time in C. There's not
much need to go out into a better language than C and do the
optimization and abstraction there. In fact everyone prefers to
optimize on the C level and not in B.
Python has a bigger problem than perl with its GIL (global interpreter
lock) which we solved with cloning the whole optree upfront, and
having seperate interpreter environments per thread.
From a global picture perls internals are much saner than pythons,
python is just much better documented. But from reading the source
code I prefer perl by far.
Why no PiP?
Because our ops are already highly optimized C code, you cannot do better.
You have to improve the optree representation, unroll, inline, use the C ABI,
or use the available static type information to be able to do better.
Then you can use custom ops, typed ops, typed method calls, and
various other optimizations. With our current ABI we are already close
to our limit,
and it's still faster than python.
> * Is this something the community already thought in?
With the perl6 discussion 10 years ago, yes.
> I see a lot of pontential but the possible factor is very important if this
> requires an humongous effort but only serves for a few use cases doesn't
> makes sense. I foresee a big problem with the XS modules but with a decent
> FFI those the list of modules requiring poking at the guts should be
> reduced.
For a really fast perl5 I thought about changing the XS ABI.
Handling our own stack on the heap is very costly, and we cannot
optimize op calls. I outlined a conversion to the C stack at
http://corehackers.perl.org/wiki/index.php5?title=C_stack
This would allow more linker optimizations, possibly with LLVM
or a decent gcc to perform optimized register allocation and reduce our current
function call overhead.
See e.g. https://www.socialtext.net/perl5/llvm or
http://cpansearch.perl.org/src/RURBAN/Jit-0.04_09/README
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/