Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Perl Programming It's funny. Laugh.

Parrots, Pythons And Things That Go Splat 43

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

Parrots, Pythons And Things That Go Splat More

Parrots, Pythons And Things That Go Splat

Comments Filter:

  • IronPython (Score:5, Interesting)

    by Hard_Code ( 49548 ) on Tuesday August 03, 2004 @09:06PM (#9874448)
    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.

    • No chance in hell (Score:5, Insightful)

      by Anonymous Coward on Tuesday August 03, 2004 @09:10PM (#9874482)
      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 (Score:5, Interesting)

        by DylanQuixote ( 538987 ) <<ten.nosidrah> <ta> <nalyd>> on Wednesday August 04, 2004 @01:05AM (#9875964) Homepage
        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!

        • Registers versus Stacks (Score:5, Interesting)

          by chromatic ( 9471 ) on Wednesday August 04, 2004 @02:01AM (#9876201) Homepage

          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.

        • Couldn't agree more. There are just some classes of programs that Java won't be able to do. CGI scripts for example. Or programs that have to be called several times in a second (like using it with tcpserver).

        • Re:No chance in hell (Score:3, Informative)

          by 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

      • 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 wh

        • Re:Type inference (was Re:No chance in hell) (Score:1, Insightful)

          by Anonymous Coward
          This astonishingly understates the difficulty in dealing with runtime typing and binding. Consider the function:

          func foo(x) {return bar(x) + 3;}

          So... what type is x? An int? A string? A stream? You can't tell because it depends on what's passed to bar. If bar's around, you could use this to infer the type of x for foo. But for many such languages, bar is loaded at runtime *and* in some of them, the type of x passed into bar can change. Compiler researchers have been arguing for a variety of runtim

          • It IS fairly hard to do, but there has come some things of it. You can look at e.g. Sun Microsystems Laboratories Technical Report 96-52 (SMLI TR-96-52), "Concrete Type Inference: Delivering Object-Oriented Applications" by Ole Agesen for examples of what has been done around Self (to take an example of type inference done around proto-based languages).

            Another form of type "inference" done at run time is type feedback; that also gives reasonable performance, and IMO much has come of it, it just isn't be

      • These languages make certain assumptions about typing and binding that Python and Perl do not.

        And which Parrot allows you to if you wish. You're discussing languages, not VMs, but responding to a comment about VMs.

        Additionally, Java's class structure is much *much* more time-efficient [...] than Python's memory-efficient proto-based object structure.

        Well, again you're comparing language features not VM features, and in this particular case, you're going to be dissapointed, because even in pure Python
      • Moderators, although I suggest that you take Eivind Eklund's advice into account, I can provide you with a shortcut to knowledge. Anyone who claims that proto[type]-based "object structures" (whatever those are) are "memory-efficient" is full of shit. I don't like to repeat myself, so I've dug up a past Slashdot post of mine [slashdot.org] (Slashdot makes this really hard to do - I think I would have saved time by re-stating my argument here) detailing the data requirements of an object in a prototype-based object system

    • Re:IronPython (Score:2, Informative)

      by CableModemSniper ( 556285 )
      Where did you get PHP from? It was CPython vs. Parrot Python. (well a translator that turns python bytecodes into parrot byte codes anyway)
    • woops, confoozled my guido-van-rossums with my rasmus-lerdorfs...

    • Re:IronPython (Score:5, Informative)

      by Anonymous Coward on Tuesday August 03, 2004 @10:27PM (#9875016)
      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.
      • 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.

        • Re:Excuses, excuses (Score:3, Informative)

          by Elian ( 10270 )
          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.
          • The python challenge scripts were available for only 6 months, but you had a full year to write a python bytecode interpreter. Anyway, Leo almost got the scripts working, to his credit.

    • Re:IronPython (Score:2, Funny)

      by DAldredge ( 2353 )
      You know, IronPython causes major problems for my sig.

    • No, it was slower! (Score:4, Informative)

      by Bazzargh ( 39195 ) on Wednesday August 04, 2004 @04:45AM (#9876815)
      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 [oreillynet.com]. 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
    • 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,

      • Re:IronPython (Score:3, Interesting)

        by Hard_Code ( 49548 )
        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

        • Re:IronPython (Score:1, Interesting)

          by Anonymous Coward
          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 i

  • Ex Parrot (Score:5, Funny)

    by complete loony ( 663508 ) <Jeremy@Lakeman.gmail@com> on Wednesday August 04, 2004 @02:35AM (#9876354)
    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!!

Slashdot Top Deals

If you have a procedure with 10 parameters, you probably missed some.

Close