Re: LuaJIT performance

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

RJP Computing wrote:
> Is there a 64bit version coming when version 2 is done?

The goal is to release the x86 version and stabilize it a bit
before starting the x64 port.

Most of the LJ2 VM is already "64 bit ready". E.g. it has an
arch-independent 32 bit pointer abstraction for all GC objects.
This keeps tagged values at 8 bytes on all platforms. But several
major areas need more work: porting DynASM to x64, porting the
interpreter (which is 100% x86 assembler), dealing with the
different x64 calling conventions (WIN64 is different than the
rest of the world) and a couple more open issues.

Michael Bauroth wrote:
> Does there exist eventually an ARM port?

Given the market share and the estimated demand, that's most
likely the next port after the x64 port. But it's much more
complicated, since there is no uniform ARM platform. The choice of
the number type for Lua is the main difficulty.

Using double-precision floating-point numbers is one option. But
it needs really fast FP arithmetics (x86/x64 provides that).
Unfortunately most older ARM devices have no FPU at all and NEON
doesn't do double precision FP. And about VFP ... well, some
vendors like to hide the fact that most of their gadgets only
contain something called "VFPlite". The high latencies and the low
throughput makes softfp suddenly look like an attractive option.

Another option is to use 32 bit integers only. Certainly easier to
implement, but I'm not so sure everyone would be happy with it.

I've also considered using 32.31 fixed-point numbers. Yes, it's a
bit of an awkward choice. But you'd get fractional numbers at the
speed of integer arithmetics. Again, I'm not sure about the needs
of developers who'd like to have LJ2 ported to ARM.

[Note that support for multiple number types per platform is not
an option. A JIT compiler needs to emit very different instruction
sequences for each number type. Switching number types is not as
easy as changing a couple of C macros.]

--Mike