I think the fundamental problem is that Perl has too many hooks (operation overloading, constant overloading, variable type overloading, custom opcodes, etc) that prevent optimizations without changing the language. We can't even guarantee that 2 returns a number (e.g. when using use bigint;), so we're stuck with fat opcodes that must be able to accept any kind of value.

Yeah, given that observing a variable at the Perl level could cause SV upgrades within an opcode, maybe it's better to say the challenges are:

• Polymorphic data structures at the C level; with
• SV upgrades in opcodes; leading to
• Large opcode function sizes

We're not talking about JITting a five line Smalltalk method that's monomorphic across 80% of calls here. It would surprise me if the average opcode didn't expand to a size larger—and quite a few basic blocks more‐than LLVM wants to try to JIT.

Nah, implicit type conversions is something JIT compilers can handle.

JIT is about optimizing the main cases and observing the edge cases.

You don't need guarantees because you just fall back to the generic solution if the input variables become unusual.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

It's the checking that makes it slow right now, so I'm not sure how what you said helps.

I also remember Steffen Müller giving a talk demonstrating some Perl JIT.