Re: Does Lua need a JIT?

[Sean Conner <sean@...>]

It was thus said that the Great Dibyendu Majumdar once stated:
> 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?
> 
> I have no data points to tell me under what conditions a JIT makes
> sense, apart from artificial benchmarks. The most obvious use case is
> games programming I guess where the highest performance is needed, but
> I am not a games programmer and do not know whether interpreted Lua is
> good enough in this case.

  I see LuaJIT useful in cases of heavy mathematics, who's speed can rival
that of C (I have some Lua code to generate a Mandelbrot set---running under
LuaJIT it's easily the same speed as a similar program in C) since LuaJIT
can optimize the heavy loops to take advantage of runtime information
(certain values never change in the loops so we can do constant propagation,
etc. etc.).

> In my opinion, having worked on Ravi and in my usage of it, Lua is not
> a general purpose language that you would use to build a large scale
> application. This is not because of any deficiency in Lua, it is more
> that large scale development is better done in statically typed
> languages like Java, C#, Go, Swift etc. The cost of developing complex
> applications in a dynamic language is just too high. I know that many
> folks on this list will probably disagree with this view, but leaving
> aside your love for Lua and your wish to use Lua everywhere, would you
> still use Lua as a general purpose application development platform?

  At work, we use Lua to parse SIP messages (using LPeg), and based on the
information given, formulate a request to a backend server to do the
"business logic" [1], receive the response from said backend server, and
reply with a new SIP message containing the information from the backend. 
And this is major---it's part of the Monopolistic Phone Company's call flow
(that is, real phone calls).  

  Granted, it's not a large application (6300 lines of Lua, excluding third
party code and modules written in C, which itself if a few thousand lines of
code) but it's still an application making our company money.  Running PUC
Lua [2].

  -spc

[1]	Caller Name ID---that is, for a given phone number, return an actual
	name associated with the account.

[2]	Even though it's all Lua 5.1, we can't use LuaJIT because the code
	runs on the SPARC architecture [3], which LuaJIT does not support.

[3]	A legal requirement for the hardware to be NEBS compliant, and Sun
	SPARC machines match that requirement.  If we could get non-SPARC
	machines that were NEBS compliant, we would in a heartbeat.