5 ms·

http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=perl&lang2=v8&data=u64 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

by lisper- 11y ago

http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=perl&lang2=v8&data=u64 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te... 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.

bane 11y ago
>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? because you can't write Perl or Python for SBCL, LuaJit, V8 or CogVM.
- lisper- 11y ago
  My point is that the effort incrementally improving these C runtimes would be better spent producing modern implementations for them with just-in-time or ahead-of-time native code compilation, like other dynamic languages already enjoy. In light of V8 or SBCL, tweaking Perl's C runtime just seems like a premature optimization.
  - hyperpape 11y ago
    I don't know about Perl, but in the case of Python and Ruby, I think there are C extensions that would have to be replaced with a JIT. So PyPy has a 5-6x speed improvement, but can't be deployed in many places.
    - SoftwareMaven 11y ago
      This hits us hard. I would love to deploy almost everything we do on pypy, but legacy code dictates the use of C modules that don't have pure python implementations that come close to the necessary functionality. Compatibility with the massive ecosystem of existing code is something everybody who says "just rewrite the runtime with X" seems to forget.
  - bane 11y ago
    Yeah, I can see that. Perl6 has gone through some rather painful VM stories trying to get to production. I'm an admitted Perl fan, so yeah, I'd love it if Perl had an ultra-fast native-speed run-time. But oddly, speed has rarely been something that's been called out as a major problem in the same way that it has been with CL, Lua, Javascript, Python etc. 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.
alberich 11y ago
>> By simply changing your language to one with a modern implementation, you can save considerable money on hardware. 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.

by lisper- 11y ago

bane 11y ago

>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? because you can't write Perl or Python for SBCL, LuaJit, V8 or CogVM.

lisper- 11y ago
My point is that the effort incrementally improving these C runtimes would be better spent producing modern implementations for them with just-in-time or ahead-of-time native code compilation, like other dynamic languages already enjoy. In light of V8 or SBCL, tweaking Perl's C runtime just seems like a premature optimization.
- hyperpape 11y ago
  I don't know about Perl, but in the case of Python and Ruby, I think there are C extensions that would have to be replaced with a JIT. So PyPy has a 5-6x speed improvement, but can't be deployed in many places.
  - SoftwareMaven 11y ago
    This hits us hard. I would love to deploy almost everything we do on pypy, but legacy code dictates the use of C modules that don't have pure python implementations that come close to the necessary functionality. Compatibility with the massive ecosystem of existing code is something everybody who says "just rewrite the runtime with X" seems to forget.
- bane 11y ago
  Yeah, I can see that. Perl6 has gone through some rather painful VM stories trying to get to production. I'm an admitted Perl fan, so yeah, I'd love it if Perl had an ultra-fast native-speed run-time. But oddly, speed has rarely been something that's been called out as a major problem in the same way that it has been with CL, Lua, Javascript, Python etc. 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.

alberich 11y ago

>> By simply changing your language to one with a modern implementation, you can save considerable money on hardware. 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.