Pugs is going great shakes - why not just toss Parrot and run Perl 6 on Pugs?
Autrijus Tang, the lead on the Pugs project, notes that an *unoptimised*
Parrot is already 30% faster than Haskell. Add compiler optimisation and a
few planned optimisations and Parrot will beat Pugs for speed hands down.
Autrijus things that Pugs could be made faster with some Haskell compiler
tricks, but it's harder work and less effective than the Parrot optimisations
we already know how to do.
Perl 5 is highly portable, and builds on around 50 different systems, many
far removed from Unix or MS Windows. We'd like Perl 6 to be able run
everywhere that Perl 5 runs, so we need to keep Parrot as portable as possible.
The Glasgow Haskell Compiler is a pain to build on minor systems, and downright
impossible on small systems. So by going with Pugs and Haskell we'd be
Finally there is a reason the Parrot design keeps talking about running
bytecode direct from disk rather than relying on doing compiling (from Perl or
with a JIT) in memory. It's all very well doing such operations when running
one program, but think what happens on a multi-user system when 300 people
fire up "parrot order.pbc" - 300 parrot processes all fighting for resources.
To quote Dan,
non-jit vss/rss is 29784 17312, JIT vss/rss is 122032 108916. A not
insignificant difference :)
With read only bytecode shared between processes, much of that "non-jit"
resident memory is going to be shared. So much less swapping. And don't think
that this won't matter to you because you don't have 300 users all running
the same program - consider what happens if each Perl 6 module is compiled to
bytecode. With read only bytecode 300 different Perl scripts all share the
same memory for Carp.pbc, warnings.pbc, etc. Without, and they're all swapping
Good answer, and other than adding a bit about cross-language usage I'd
stop there (memory issues are important but complex, and you've already
made your point with this brief answer).
The next question is:
Q: OK, so Parrot is fast... Pugs can back-end to Parrot, right?
A: Yes (though at this time, that's in the early stages). Still, the
ultimate goal is for Perl 6 to be self-hosting (that is, written in
itself) in order to improve introspection, debugger capabilities,
compile-time semantic modulation, etc. For this reason, Pugs will
probably be the compiler that first compiles the ultimate Perl 6
compiler, but thereafter Pugs will no longer be the primary reference
implementation. This is documented by the Pugs team at
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Beyond all that, there is the point that many other languages are
being implemented to Parrot, and we have a nice hope of some
cross-language compatibility there. Speed considerations aside,
are there Python/Tcl/Ruby/other language implementations existing
or in the queue for Haskell? (Although I would guess there certainly
could be. :-)
And, just for completeness, I'd like to repeat my appreciation for
the truly impressive work that Autrijus and Co. have been doing.
I believe they have likely shaved months off of the development
of the Perl6 -> Parrot compiler. At any rate, it's great to have
a Perl 6 implementation to be playing with, and with Pugs' help
I fully hope/expect that we'll have some form of native Perl 6 ->
Parrot translator sometime this summer.
> Based on the wheat on IRC this evening, is this question/answer worth adding
> to the Parrot FAQ on parrotcode.org?
> Pugs is going great shakes - why not just toss Parrot and run Perl 6 on Pugs?
[snipped long response]
and let's not forget bytecode compatibility with all the non-perl
languages that will hopefully target parrot.
> With read only bytecode shared between processes, much of that "non-jit"
> resident memory is going to be shared. So much less swapping.
Yeah. Yesterday I wrote:
$ parrot -j -o order.pbc order.imc # emit jitted code
Well, that was rather wrong. But we have on some systems ...
$ parrot -o hello.pbc hello.imc
$ parrot -o hello.o hello.pbc
$ make EXEC=hello exec
... at least the basics to create a JITted, sharable executable.
> Nicholas Clark
> [snipped long response]
> and let's not forget bytecode compatibility with all the non-perl
> languages that will hopefully target parrot.
On Wed, Mar 30, 2005 at 03:49:54PM -0500, Aaron Sherman wrote:
> On Wed, 2005-03-30 at 14:58, Nicholas Clark wrote:
> Good answer, and other than adding a bit about cross-language usage I'd
> stop there (memory issues are important but complex, and you've already
> made your point with this brief answer).
Patches welcome, as I'm not sure of the best way to phrase the cross
language stuff to follow on smoothly.
> Patches welcome, as I'm not sure of the best way to phrase the cross
> language stuff to follow on smoothly.
Also, Parrot provides access to Perl 6 from other languages and to those
other languages from Perl 6 at run-time, a feature which is both complex
and highly beneficial for all concerned.
One possibility is attached.
Interdisciplinary Biophysics, University of Virginia