How we spent two days making Perl faster
blog.booking.com
blog.booking.com
The other thing is that Perl's built in data structure primitives have somehow hit a magical balance between performance, ease of use and power. Once you get used to the syntax, arbitrarily composing complex data structures is super-easy and they usually perform extremely well.
I think what's surprising is how snappy the language feels in aggregate, even if it benchmarks fairly slow. From execution to runtime, it just feels snappy and I think that may give it a false sense of performance while modern Java and C++ etc. really are faster, they have a clunky feel and lots of the user-facing things seem kind of creaky.
One other problem is that it's really easy to write really slow code in other languages, but even if you only do things mildly "the Perl way" it'll still run reasonably quick.
To this day, I'm still amazed at how many little Perl prototype projects I've written that outperformed their compiled rewrite cousins for months until lots of time was spent specifically tuning that rewritten code.
edit sorry for words I'm beer-posting tonight
http://benchmarksgame.alioth.debian.org/u32/which-programs-a...
Perl is solidly in the lowest tier of serious language performance, and that result is quite robust no matter how you query that site, and correlates to my personal experiences as well.
Perl isn't alone... it's joined by many of its 1990s-style dynamic scripting language buddies with very similar performance. And of course many fine programs are written in them nevertheless, so I don't mean this as a criticism... in fact if you read this as a "criticism" that needs to be "rebutted" in some sense you're entirely missing my point. I really shouldn't have to "qualify" this to fend off the obvious replies, but I've been around enough to know I do. But, it's true that a serious professional should be aware that Perl is in the slowest executing set of languages, and it is very possible for the difference to be significant for you in many commonly-occurring tasks.
Perl has a lot of built-in functions, keywords, and operators. It's also a bytecode-compiled language (yeah, Perl is compiled when you run it, the compiler is just so fast you don't notice it.) But a lot of those built-ins don't compile to the bytecode equivalent of machine code for a VM like you might expect; they compile to a single instruction that's got an optimized implementation written in C. When you write idiomatic code, you tend to use built-ins in a way that allows those optimized instructions to be used, which gives you near-C level performance.
For example, if you want to loop over every member of a list, perform an operation on each member, and produce a new list based on the results of those operations, you could use a 'for' loop for that. But if you do than the Perl compiler needs to produce bytecode that mirrors the generic for loop and the full code in the body of the loop, pretty much as you wrote it. The compiler can't make any assumptions about the intended behavior. If you instead use the 'map' keyword, the compiler knows that you're transforming one list into another by running a bit of code on each member of the list, and it'll produce much more optimized code to do that.
It's kind of ironic. You can write 'C' style code in Perl but you won't get C-like performance that way, you'll get Perl-like performance. But if you write 'Perl' style code instead, you'll get C-like performance.
But you're right, Perl's implementation of this strategy isn't like classic Pascal or modern Java's implementations. But that doesn't alter my point; writing idiomatic Perl gives you a smaller AST with symbols that execute optimized code.
You're also right about Perl not having C-like performance for anything computational, because there you're dealing with Perl's data types, which are powerful and flexible but not efficient, as the article describes. My point was more about looping, set operations, string manipulation, conditional statements, and data structures. Perl has both efficient and inefficent ways to handle all of those, and it pays to learn to use the efficient expressions.
You know, the picture becomes to come into focus to me. I suspect due to the prevalence of the saying "Languages don't have performance, only implementations do" and people constantly slagging on benchmarks without thought, simply reflexively, and probably helped by a healthy dose of both fanboyism and instinctive revulsion to fanboyism, programmers are apparently nearly completely incapable of having a reasonable discussion about which languages are faster than other, at what tasks, under what circumstances.
Well, that's a pity, because there is such a discussion to be had, and a lot of people are getting hurt because of their inability to get good information on this topic, and consequently making perfectly-avoidable bad decisions. Absolute statements are hard to come by, sure, but there are engineeringly-useful guidelines that you can discover if you examine the problem space.
I try to imagine a discussion between carpenters about chisels, saws or hammers and each having a favourite brand that they'd defend to the death in order to avoid an objective discussion about what the good and bad properties of each tool are.
Where there is choice people will complain about the choices of others.
After all, programming languages are just tools. What really matters is the applications you create with them, and that people will find your application useful and use it with pleasure.
Up to that point it is just your preference.
Ironically, you're being prickly in exactly the wrong direction. Perl is totally a serious language. I do most of my work in it, in fact. I qualify it with "serious language" because when I say it's one of the slowest serious languages, it's no fair to counter that by pointing out somebody's hobby implementation of Lispcheme that's a hundred time slower.
"In its class of languages Perl is one of the fastest."
Well... I suppose... since essentially all original C-interpreter implementations of the 1990s-style dynamic scripting languages have performance within about 20% of each other, that's not false... but the marketing-style implication that Perl is the fastest certainly is false. (Also LuaJIT is way faster, but does "compromise" relative to some Perl features to get there.) Drop the "C-interpreter" clause and Perl's in real trouble... Javascript isn't the C-speed language it sometimes gets presented as but JIT'ed JS really will handily beat Perl, and PyPy is... weirdly complicated from a performance perspective.
The point is still that talking about Perl as a perfomant language on almost any measure is... very weird. It's not. It's possible to name several serious languages which are as slow, but not one that clearly slower.
Using perl, you can not win speed benchmarks, but a C program significantly faster than the "normal" perl program, needs much much more development time.
I have already encountered a C project that was rewritten in perl because it was a maintenance nightmare. The client was very surprised by the performance increase.
I do not know what are your "commonly-occuring" tasks, but in my experience, perl performance was never the bottleneck.
It even seems from those benchmarks you posted Perl did quite well in the reverse complement and regex DNA tests, as I would have expected.
You have to remember this idea comes from the late 90s when Java was slow as a dog, and Perl solidly cleaned the floor with other scripting languages like Python, Tcl, (was Ruby even known then?).
Perl even outpaced C++ for I/O related stuff due to the way Perl buffered input (or maybe the way C++ streams were so badly implemented). Of course a clean slate implement in C++ that avoided...well C++...and used mostly C style code would have cleaned the floor with Perl...but that was the state of C++ in the 90s.
Yeah...Perl had its heyday.
I use them also daily to come up with similar optimizations, but on a grander scheme, to support proper type optimizations (which might reach the php/lua/javascript performance range then).
But to be fair: Bodyless NV's and cached class pointers for methods are the biggest win in 5.22. OP_SIGNATURE didn't make it.
http://cpansearch.perl.org/src/RURBAN/illguts-0.49/index.htm...
The results for MRI and CPython are similar. I hate to sound harsh, but what's the point of incrementally optimizing perl, MRI, or CPython when the result is still going to be an order of magnitude slower than SBCL, LuaJit, V8, or CogVM? In fact, I suspect enough person hours have already gone into optimizing these C runtimes that had they known better when they started, they could have already had something like SBCL by now.
Performance matters. By simply changing your language to one with a modern implementation, you can save considerable money on hardware. The argument that Perl/Ruby/Python are so much more expressive/powerful/whatever and therefore are worth the added cost is much less compelling when there are other, comparably dynamic languages like JavaScript with implementations that are much, much faster.
because you can't write Perl or Python for SBCL, LuaJit, V8 or CogVM.
Compatibility with the massive ecosystem of existing code is something everybody who says "just rewrite the runtime with X" seems to forget.
It may also be that Perl 5 has always more or less had one implementation and has all kinds of messy parsing rules, so nobody bothered to complain since we all knew it was a disaster trying to sort that mess out.
Well, maybe thay can save even more money on developers by not switching languages. After all, if raw performance was all that matters people would probably still be programming in assembly.
Ruby 3.0 has a grand plan for JIT, removal of GIT and everything. Perl 6 is catching up, PHP 7 doubled its speed and will release this year.
Source? AFAICT, the Ruby community has in the last couple years just started talking seriously about ideas about what Ruby 3 might look like, but there is no "grand plan".
It's from RubyKaigi 2014
video https://www.youtube.com/watch?v=zt56zjNf84Q
You are right, it's about what Ruby 3 might look like
http://gimpfoo.de/2012/04/17/goat-invasion-in-gimp/
"What was planned as a one week visit turned into 3 weeks of GEGL porting madness. At the time this article is written, about 90% of the GIMP application’s core are ported to GEGL..."
That was in 2012 and it's still not done. Almost, but not yet.
There are equivalents in software, for example the removal of the GIL in Python (never done sucesfully in the sense that the majority of users started using it) or, equivalently, the effective GIL in OS kernels (done successfully a couple of times, AFAIK, even though it theoretically requires inspection of all driver source code)
A JIT-ted Python similarly may eventually be the better choice, but the road getting there may be long and harsh.