Re: LuaJIT performance

[Mike Pall <mikelu-0908@...>]

Dirk Feytons wrote:
> I know next-to-nothing about JIT so the following might sound
> ridiculous: would it be possible to combine Asko's LNUM patch with
> JIT?

Certainly not the patch itself. Maybe the basic idea of having a
dual number representation. But the semantics can get quite ugly
(overflow handling and preserving -0).

Case in point: Mozilla's SpiderMonkey JavaScript engine uses such
a dual number representation (int31 vs. boxed doubles). The
interpreter always converts all operands to doubles, performs a
double-precision FP operation and then checks whether the result
is in range of int31 to avoid boxing it. Ok, so that's not exactly
helpful without a hardware FPU.

Their TraceMonkey JIT compiler can turn this into a check for
integer overflow in many cases. But the required logic for
managing the two number domains looks excessive. Has anybody ever
dared to run Firefox on a FP-challenged ARM box with JS-intensive
apps? Whee ...

Of course one can go crazy optimizing this with special bytecodes
for each case, patching the bytecode at runtime depending on the
observed domain of its operands (like a polymorphic inline cache).
Same goes for the JIT compiler.

Not sure I want to go down this path. A pure int32 VM suddenly
looks really easy in comparison. ;-)

--Mike