Slashdot Mirror

← Back to Stories (view on slashdot.org)

Parrots, Pythons And Things That Go Splat

Posted by timothy on from the stage-condom-is-a-slippery-meme dept.

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

6 of 43 comments (clear)

  1. IronPython by Hard_Code · · Score: 4, Interesting

    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?
    1. Re:IronPython by Hard_Code · · Score: 2, Interesting

      What is interesting to me is dynamic optimization of long-running processes through a dynamic jit/unjit. Java has one, but as far as I know Mono/.Net does not (all the compilation is up-front, not while it runs).

      I think a lot of these performance comparisons will become moot in the face of a runtime optimizer because who's static optimizations are better than others' won't matter when you have an optimizer that operates at runtime and dynamically inspects what code is actually being executed and optimizes that. I sure hope Mono/.NET get a dynamic runtime optimizer. It will make all these arguments pointless.

      --

      It's 10 PM. Do you know if you're un-American?
    2. Re:IronPython by Anonymous Coward · · Score: 1, Interesting

      I think a lot of these performance comparisons will become moot in the face of a runtime optimizer because who's static optimizations are better than others' won't matter when you have an optimizer that operates at runtime and dynamically inspects what code is actually being executed and optimizes that.

      And life will be wonderful in heaven, where the lion lies down with the lamb[1] and baby Jesus is always smiling and the choir of saints sings sweet hymns to the Almighty and Java runs faster than C.

      Back in the real world, runtime optimisation is still an unproven pipe-dream. Static languages are still faster than dynamic languages and machine code is still faster than bytecode. Let's be realistic here - fusion power never happened, and it's quite possible that runtime optimisations beating compile-time optimisations will go the same way.

      [1] And we all know what "lie down with" means in the Bible. Like, ewww.

  2. Re:Both slower than Java tho... by Dan+Ost · · Score: 4, Interesting

    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?

    --

    *sigh* back to work...
  3. Re:No chance in hell by DylanQuixote · · Score: 5, Interesting

    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!

  4. Registers versus Stacks by chromatic · · Score: 5, Interesting

    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.

    --
    how to invest, a novice's guide