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? 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 sacrificing portability. 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 like crazy... Nicholas Clark
