Re: High Performance Perl

[jonadab]

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.

So you end up with progammers using these things all the time without thinking, because "it'll be faster", and that's "better". This is a perpetual source of bugs, because when you optimize without thinking, you make promises and then don't keep them. You end up making boneheaded blunders, such as storing numbers in that array of ints that come from an integer field in a database, only to discover much to your chagrin that the database uses 64-bit integers, causing your program to blow up on 32-bit systems.

Ever wonder why every third newly-discovered security vulnerability in some app or another is a buffer overflow, a particularly preventable type of bug that has been well understood for thirty years? It's because C programmers don't want to take the (usually insignificant) performance hit of using a proper string-handling library with sane semantics. "I'm sure an email header will never be more than this many bytes, because the RFC says so." C makes it particularly easy to do this sort of misguided optimization, because it is the default behavior. That's a Very Bad Thing.

Sure if the optimization features were optional and off by default (as they will be in Perl6), a properly disciplined programmer could force himself to only use them after careful consideration and, when maintaining the code, to think before every change, "what optimizations does this change impact, and does it invalidate any of my promises?" There are, if I am not mistaken, at least three programmers in the world with the self-control and mental presense to program that way. But for *most* programmer's, it's a nightmare waiting to keep you up nights figuring out *why* your program is crashing. My advice will be, never use the optimazion features unless you can prove (with profiling) that it's necessary.

Perl6 is going to have the optimization features. When people start adopting it, we're going to see a large increase in the general bugginess of Perl software written by people who use those features. The first thing I'm going to ask people when they have a bug is, "Did you turn on stupid unnecessary optimizations? Did you try turning them back off, and see if the problem magically goes away?"

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

[audreyt]

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.

[jonadab]

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.

[audreyt]

Sure. You solve it by doing whole-program analysis, and preferably restrict eval "" calls to not able to add ad-hoc bindings to Int.