Comments on: Does Perl need a JIT?

By: Jared

Jared — Mon, 06 Jun 2011 20:55:12 +0000

Hi Michael,

I agree it would be nice if Perl got a JIT, as I said in my second line. However, I don’t think it *needs* it.

If VM speed was that important for scripting languages, everybody would use Lua (and LuaJIT) rather than the P-languages. PyPy would have killed off CPython, etc.

And again, right, it would be nice if your Starman app ran faster for free. But really, how much difference would it make for 99% of Starman apps. Would it make sense to devote finite development resource to a JIT rather a different, more useful Perl enhancement?

No, in my opinion.

By: Fulko

Fulko — Mon, 06 Jun 2011 14:41:45 +0000

I’d rather have a usable (up-to-date/finished) version of B:: or equivalent where I could ship a packaged product or P-code rather than ‘a set of source code and CPAN library components’.

…but I also agree with the ‘long running persistent application’ issue too.

By: Michael Peters

Michael Peters — Mon, 06 Jun 2011 14:18:49 +0000

I totally disagree. Lots of people write persistent long running web applications in Perl (using mod_perl, FastCGI or these days something like Starman) and having an optional JIT that would optimize it as it ran for days or weeks would be an amazing feature to have.

By: nerdscentral

nerdscentral — Mon, 06 Jun 2011 09:55:14 +0000

Hi,

I tend to agree, Perl’s ast based internal structure is very fast. The overhead of JIT would almost certainly be a big down side as most perl programs seem to run for a very short time. JIT makes more sense in a language designed from the ground up to be multi-threaded and memory safe so applications run for a long time in a server type role.

I think the future of Per is much more wedded to tooling – debuggers, IDEs etc. The internals of the language are pretty mature and it is hard to see much benefit with change of change’s sake.

Best wishes – AJ