4 ms·
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-
by 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 agoI 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 agoThis 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 agoYeah, 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.