Re: Does Lua need a JIT?

[Ahmed Charles <acharles@...>]

On 2/21/2017 1:12 PM, Dibyendu Majumdar wrote:
> Hi,
> 
> Related to my post about why I have not used the JIT technology in
> Ravi for my project (yet), is the question: do we need a JIT for Lua
> at all?

Disclaimer: My preferred languages are either C++ or Rust for heavy
lifting and Lua for scripting (though, I don't script very often).

If one takes a step back and thinks about why people use JIT for a given
language, it's exclusively about performance. If performance wasn't a
factor, an interpreter would be preferred because it's easier to
maintain and write.

So, given that JIT is about performance, one might wonder what
properties of code allows JIT implementations the best chance of
delivering better performance? Well, code which always passes the same
objects of the same types to the same functions, allow for the easiest
time achieving good performance with JIT. Basically, write exactly the
same code as you would in a statically typed language (without a
compiler to help you get it right) and you'll get better performance.

My hypothesis is thus, that if one finds themselves needing a JIT
implementation for their dynamic language, they've chosen the wrong
language for their requirements (or their requirements changed in some
unexpected way that was not appropriately anticipated).

JIT implementations for languages that are statically typed seem even
weirder, since the Just-In-Time part isn't required and you can just
compile the code once on the target at install time. .NET has supported
this for a while, but I have no idea how often it's used.

The one scenario that is ideal for JIT is actually language agnostic and
that is for situations where it is desired that code be delivered and
run on an arbitrary architecture as quickly as possible. For example,
visiting a web page and having complex interactions, like a game. But,
rather than that being a justification for using a dynamic language
(i.e. JavaScript), it should be viewed more as a reason to have
webassembly, which is a language agnostic, ISA-like binary format
designed with sandboxing in mind while allowing relatively easy
translation from it to a given architecture's machine code. The fact
that webassembly is JIT compiled is as relevant to the average
programmer as the fact that all modern x86 cpu's are just JITing x86
assembly to proprietary microcode on the processor.

Anyways, language choice should be based on the problem domain and the
anticipated performance requirements thereof. Implementing really
complex JIT for a specific language is just a sign that a codebase
written in that language achieved more success than the original writers
anticipated. Note, whether or not that success would've been possible if
a different language were chosen initially is next to impossible to
determine. Though, all 'successful', language specific JIT
implementations that I know of follow this pattern.