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."

10 of 43 comments (clear)

  1. Re:IronPython by CableModemSniper · · Score: 2, Informative

    Where did you get PHP from? It was CPython vs. Parrot Python. (well a translator that turns python bytecodes into parrot byte codes anyway)

    --
    Why not fork?
  2. Re:IronPython by Anonymous Coward · · Score: 5, Informative

    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.

  3. Re:Benchmarks aren't everything by hattmoward · · Score: 2, Informative

    Wha? What?

    Who said anything about the running speed? Didn't I just discredit that? The point was that a programmer knowledgable in Perl, Python, and Java would most certainly implement the program very quickly in Perl or Python.

  4. No, it was slower! by Bazzargh · · Score: 3, Informative

    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.

  5. Re:No chance in hell by gredman · · Score: 1, Informative
    CGI scripts for example.
    Isn't that what servlets are for?
  6. Re:IronPython by anonymous+cowherd+(m · · Score: 2, Informative
    You also have to keep in mind that IronPython is not yet a complete implementation. I love python as a language, and if IronPython turns out to be faster than CPython in a way that matters to me, then I'll switch. I'm not tied to a particular implementation at all.

    OTOH, I do think it's going to be pretty hard to beat the combination of CPython and psyco. I've achieved speedups on code I've written of up to 24x, and it's claimed one can get up to a 100x speedup on certain limited types of code.

    OTOOH, the types of code that psyco tends to speed up that dramatically tends to be rather non-pythonic in my experience. My best experience was with number crunching code using regular ints -- that's clearly a job for a C extension and I fail to see how any VM can beat raw C consistently for that type of code, unless it has one hell of a JIT compiler. But then, that's exactly what psyco is...

    --
    http://neokosmos.blogsome.com
  7. Re:No chance in hell by Anonymous Coward · · Score: 3, Informative
    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.
  8. Re:Registers versus Stacks by chromatic · · Score: 4, Informative

    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.

  9. Excuses, excuses by truth_revealed · · Score: 2, Informative

    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.

    1. Re:Excuses, excuses by Elian · · Score: 2, Informative

      No, I had six months -- the benchmark wasn't written until early January this year, at which point I had more important things to do and put it off. For too long as it turned out, since I didn't even take a serious look at it until late May.

      This was never a "Python people" vs "Parrot people" bet. It was personal, between Guido and me, and I didn't factor in enough time to allow for delays, so I lost.