Slashdot Mirror
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."
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.
It's 10 PM. Do you know if you're un-American?
...of course, one would not expect late-bound languages like Perl or Python to compete with Java in that regard. But in my experience PythonC runs my benchmarks at just over 1/10 the speed of HotSpot. Surely they can improve on that.
Perl's speed actually surprises many, but speed isn't everything that should be considered in a language. The bet between Guido and Dan was on a completely academic level, not a pubescent drag race. =) Quick, get me a Java app that scans a set of maildir directories and outputs all messages by "TmdrCaco" to STDOUT in mbox format!
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.
Tell me about it. I'm a day or two from checking in simple-but-useful OpenGL bindings.
how to invest, a novice's guide
Well, I'll soon fix that then.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
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.
...though only for tests that Parrot can implement right now. See http://lambda-the-ultimate.org/node/view/141
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
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
The Parrot team had ONE YEAR to complete the Pie-thon task - the challenge was made at OSCON 2003 for crying out loud! Meanwhile in less time than that the IronPython guy wrote a complete (and fast) Python to CLR translator by HIMSELF. Sorry, but the Parrot team's "dog ate my laptop" excuses don't hold water.