Parrots, Pythons And Things That Go Splat

ajs writes "As you may know, there was a contest between Dan Sugalski and Guido van Rossum over the performance of Parrot running Python byte-code, and the loser was to take a pie in the face. Well, in the end it was between Dan and time and Dan lost... he was unable to get the Python bytecode translator to work sufficiently well for the contest (it was fast, but not complete), but when Dan conceded, Guido was gracious enough to decline to throw a pie, what a sport! The Perl community, however, was not quite so gracious (they wanted to see Dan take a pie for the team), and the final event ended up being a benefit for the Perl Foundation. Meanwhile, see Dan's Blog for details on what sorts of Parrot goodness came of this."

Comments

IronPython

[Hard_Code]

Huh? IronPython is even faster that the normal C impl, so I guess it was more a contest of the Parrot VM than it is php vs. python. Don't worry, I have faith Parrot will be as good as the other VMs (Java, Mono) and at least on par with, but most probably faster, than a hand-rolled php engine.

Re:IronPython

[Anonymous Coward]

Huh? IronPython is even faster [slashdot.org] that the normal C impl, so I guess it was more a contest of the Parrot VM than it is php vs. python. Don't worry, I have faith Parrot will be as good as the other VMs (Java, Mono) and at least on par with, but most probably faster, than a hand-rolled php engine.

Let's not jump to conclusions, everyone. While he did lose the challenge, it seems that he lost itbecause there simply wasn't enough time to implement the functionality required to run the python scripts on the Parrot interpreter. Hopefully, the parrot interpreter would win this contest if it the developers had more time. See below for a quote from the concession:

This concludes the effort to implement the Pie-thon benchmark for
OSCON, because there isn't any chance to implement the needed bits for
b0.py in the remaining time.

Four of seven benchmarks are running: b1, b2, b3, and b6. b5 is done
partially. Three of these are faster on Parrot, but e.g. while b2.py
is running 3 times the speed of python, it takes just 0.2s here on a
Pentium 600, which makes it hard to say, what's faster for these test
collection.

The benchmarks are mainly testing the speed of builtin functions,
which are of course mature and optimized in Python, while a lot of the
builtins just didn't even exist in Parrot a month ago. When it comes
to just running arithmetic code, like in b2.py, Parrot is a lot
faster.

No chance in hell

[Anonymous Coward]

I have faith Parrot will be as good as the other VMs (Java, Mono)

These languages make certain assumptions about typing and binding that Python and Perl do not. Additionally, Java's class structure is much *much* more time-efficient (though I rather like it less) than Python's memory-efficient proto-based object structure. It's the nature of the languages. It's why they're SCRIPTING languages. They traded speed for ease of coding. Which is just fine. But don't oversell them, you just look foolish.

Re:No chance in hell

[DylanQuixote]

it is also worth noting that scripting languages tend to have a faster startup time than java-esque languages. In general, anyway.

On my 450mhz PII, running a simple java application takes a few seconds to start, while the equiv. perl
or python program starts up without any noticable delay.

And perl has to compile the program before it runs it...

Parrot vs. JVM is going to be very interesting,
too. JVM is a stack-based VM, while I believe Parrot is register-based (like most real machines, actually. :) and I've heard this difference might prove faster.

Plus writting in parrot asm is fun!

Re:No chance in hell

[Anonymous Coward]

it is also worth noting that scripting languages tend to have a faster startup time than java-esque languages.

Yes, but that's a one-shot cost. True, for quick and dirty cgi-bin execution it piles up. But for anything that takes longer than several seconds it's lost in the wash.

Parrot vs. JVM is going to be very interesting, too. JVM is a stack-based VM, while I believe Parrot is register-based (like most real machines, actually. :) and I've heard this difference might prove faster.

This is largely an issue of translation. It's tougher (read: takes longer) to efficiently translate a stack machine into native code than it is an infinite register machine. But it's still quite doable. While Parrot (like .Net) is register-based, this is only a minor advantage which is quickly lost compared to the big stuff: Python is dynamically bound with a proto-style object lookup. That's the bottleneck. The other stuff is small potatoes.

Re:Both slower than Java tho...

[Dan Ost]

But in my experience PythonC runs my benchmarks at just over 1/10 the speed of HotSpot.

Is that before or after you turn on psyco?

Registers versus Stacks

[chromatic]

Parrot is indeed register based. At least when compared to Perl 5, this is a tremendous advantage. Perl 5's VM spends a lot of time fiddling with its stack (pushing a marker on, pushing arguments on, pulling arguments off and checking for a marker) that Parrot can avoid altogether. Of course, that means that Parrot needs to spend time saving and restoring register stacks, but Dan's position is that there's enough good research on the subject to make optimizations practical.

Plus writting in parrot asm is fun!

Tell me about it. I'm a day or two from checking in simple-but-useful OpenGL bindings.

Re:Registers versus Stacks

[chromatic]

Parrot's register scheme really does help, as do PMCs, which allow much better polymorphism and much better extendability than Perl 5's built-in ADTs. Of course, the JIT and scary goto core don't hurt op execution and dispatch either.

I didn't mention that I prefer PIR so as not to confuse people, but you're right -- I much prefer writing for IMCC than for raw Parrot. Thankfully, having to care about the distinction mostly went away a long time ago.

Ex Parrot

[complete loony]

What? not a single monty python parrot sketch quote yet?
Well, I'll soon fix that then.

'E's not pinin'! 'E's passed on! This parrot is no more! He has ceased to be! 'E's expired and gone to meet 'is maker!
'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies!
'Is metabolic processes are now 'istory! 'E's off the twig!
'E's kicked the bucket, 'e's shuffled off 'is mortal coil, run down the curtain and joined the bleedin' choir invisibile!!

THIS IS AN EX-PARROT!!

No, it was slower!

[Bazzargh]

In fact, in the presentation on IronPython at OSCON, they also did the Pie-thon benchmark and IronPython WAS SLOWER than CPython. See the presentation. IP was 70% faster than CPython on the PyStone benchmark, which was what's been written about in the past, but on the Pie-thon benchmark, it came out about 4% slower (slides 24, 25). While IronPython was faster on most of the individual bits of the benchmark, he would have been pied in the face as well.

Its interesting to do a head-to-head comparison of the benchmarks Parrot completed (speedups are relative to CPython):

b1: IronPython 2.1x faster, Parrot 1.2x faster
b2: IP same speed, Parrot 3x faster
b3: IP 1.5x faster, Parrot 2.1x slower
b6: IP 1.2x faster, Parrot 1.5x faster

Score: 2 each. Both authors claim they can improve their benchmarks significantly yet, but you have to feel it will be easier for Dan as he's optimising the VM itself, Jim Hugunin can only optimize his IL output for an existing VM.

Type inference (was Re:No chance in hell)

[Eivind Eklund]

Moderators, PLEASE DO NOT MODERATE INSIGHTFUL UNLESS YOU KNOW THE SUBJECT AREA! The text quoted below (parent of this article) is full of simplistic (and wrong) assumptions, and do NOT deserve an "Insightful".

These languages make certain assumptions about typing and binding that Python and Perl do not. Additionally, Java's class structure is much *much* more time-efficient (though I rather like it less) than Python's memory-efficient proto-based object structure. It's the nature of the languages. It's why they're SCRIPTING languages. They traded speed for ease of coding. Which is just fine. But don't oversell them, you just look foolish.

Having looked reasonably deeply at the type inference space, this comment seems wrong to me. The division between "scripting languages" and "compiled languages" is superficial. The idea that doing type declarations etc makes a crucial difference is superficial. And the idea that a class is implemented the same way in the compiled code as in the executed code - that's extremely superficial.

The static (visible, programming level) declarations of type information in Java/C++/etc makes it much easier to write a compiler that generates reasonably fast code. You just follow the type specifications, leave all abstract types as the abstract types, and use a doubly indirected jump table to resolve abstract methods.

I've seen a non-optimizing C compiler done in three days of intense work by one programmer - and the inheritance/object/abstract methods addition here is fairly trivial.

Similarly, a simple interpreter is easy to write. I've done one in a day for a simple Lisp dialect. And yeah, they're slow.

However, this stuff is 1950s technology. FORTRAN came in 1956 (with an amazing optimizing compiler that competed with hand-written assembly), Lisp with an interpreter in 1958-1959 (depending a bit on how you interpret the history). What's interesting today is what we can do with type inference, constant propagation, partial evaluation, memory and cache use optimization, etc. And then the picture changes.

To be able to handle abstract types effectively, you need to do type inference to find out what actual method will be called by each abstract method call, in order to be able to do partial evaluation and constant propagation through the methods. And - guess what - that's the same stuff you need to do for all methods and variable lookups in a fully dynamic language.

In other words: The same problem is there for compiler writers, and has to be solved for a fast compiler. You get SOME extra information from the type declarations, but this information is usually the same you would get for the first pass or three of the type inference engine.

So, for good compiling/execution of Java/C#, I would start doing speculative execution with partially evaluated expressions taking the place of variables in my execution path, resolving these to constants when I can. Different code prefixes (relevant system state parts) result in re-evaluation of the pseudo method call, noting if this makes a difference in evaluation, and either registering the prefix on a new resolution block or adding it to an old resolution block. When all resolution blocks have become non-changing (no more information is being aquired through partial evaluation), I'd stop the partial evaluation and do (virtual machine) code generation.

For good compiling/execution of Ruby/Python/Perl, I would start doing speculative execution with partially evaluated expressions taking the place of variables in my execution path, resolving these to constants when I can. Different code prefixes (relevant system state parts) result in re-evaluation of the pseudo method call, noting if this makes a difference in evaluation, and either registering the prefix on a new resolution block or adding it to an old resolution block. When all resolution blocks have become non-changing (no more information is being aquired through partial ev