in reply to High Performance Perl

Perl is a highly dynamic language. A compiler can't optimize much because the programmer is allowed to change the world. Optimizations can only happen when you have guarantees. Perl 5 doesn't have much in the way of letting the programmer tell the compiler, "hey, this is an array of ints and I'll never ever put anything but ints in it" (for instance). Perl 6 has much more capability in this regard.

I'm curious though about why/where people would say that perl doesn't have great performance. Of course perl isn't going to be as fast as C for most tasks because perl is interpretted bytecode. But where Perl really wins is in programmer productivity. I don't have an online reference handy, but in the book "The Practice of Programming" Kernighan and Pike use several languages to implement the same task. A table on page 81 of that book shows the run time and number of lines of code for each language. C had the fastest runtime at .3 sec but also had the most lines of code at 150. Perl on the other hand came in second in runtime at 1 second but was only 18 lines of code. Sure, the perl code is probably denser, but I'd still be willing to bet that it took far less time to write and debug those 18 lines than it did to write and debug those 150 lines. And the actual run time for the perl implementation was fast enough and that's often what matters.

duff

Replies are listed 'Best First'.
Re: High Performance Perl
by jonadab (Parson) on May 25, 2005 at 12:30 UTC
    Perl 5 doesn't have much in the way of letting the programmer tell the compiler, "hey, this is an array of ints and I'll never ever put anything but ints in it" (for instance)

    And if Perl5 did have that, it would be a neverending source of problems. I was gravely disappointed when I heard Perl6 will have some of this sort of misguided nonsense.

    The problem with having those sorts of optimization misfeatures is simple: many programmers don't know better than to use them.

    Read more... (2 kB)
    I'm curious though about why/where people would say that perl doesn't have great performance.

    People who don't know Perl use this as an excuse to avoid learning it. It's a meme that took hold eons ago, and it was probably even true at one time, in the pre-5 era. But in fact, Perl5 today has *astonishingly* great performance, considering everything that it does. If you try to duplicate all of Perl5's features, or even the major ones, using C libraries, it's not likely to be faster. (Granted, some programs don't need all those features.)

    And the actual run time for the perl implementation was fast enough and that's often what matters.

    Here it is: the only times I've had Perl be notably slow were times when I got careless and did something that would be slow in any language, such as store several hundred megabytes of data in an enormous nested hash on a system with 32MB of physical RAM (to process a year-end report; since it ran once a year, I could afford to let it run for a while), or the time I inadvertently coded an O(N!) algorithm that used RAM proportional to runtime. (I wasn't concerned about efficiency because I knew N was never going to exceed 20 or so; O(N^2) would have been fine and dandy, but O(N!) was too much, obviously. Actually, it was O((N^2)!); it worked fine for N=2, but when I tried to run it on N=3 the swapfile grew until I ran out of drive space.) No language feature can make that sort of thing efficient. (There *are* things that are noticeably slower in Perl than in C; I've just never written code that demonstrates this. I've been writing Perl since 2000 May. In summary, it's not an issue that comes up very often in practice, so don't sweat it. On the rare occasion that you run into one of those situations, you can treat the Perl version as a prototype.)

    "In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."  — Pratico & Van Pelt, BBHG, p68
[reply]
      I do agree that blindly using unboxed types (like Perl 6's int) is a Bad Idea. Actually, all uses of unboxed types, except in very tightly contained and verified places, are potential disasters waiting to happen.

      I'd much rather the Perl 6 compiler being able to infer when it is safe to use unboxed types, and only apply unboxing optimisations when it is sound to do so. At least, that is my goal in my work on Perl 6 to Parrot codegen as part of Pugs.

[reply]
        I'd much rather the Perl 6 compiler being able to infer when it is safe to use unboxed types

        Yeah, that'd be cool. Let me know how you solve the halting problem.

[reply]

In Section Meditations