Re: Drawing the line between speed and simplicity/elegance

[Sean Conner <sean@...>]

It was thus said that the Great Rena once stated:
> On Sat, May 9, 2015 at 1:01 PM, Roberto Ierusalimschy
> <roberto@inf.puc-rio.br> wrote:
> >> Using the C API will make LuaJIT's performance bottom out. If you're
> >> worried about performance across VMs, stick to pure Lua.
> >
> > That is not a valid advice across VMs. C code is much faster than
> > (non-JIT) Lua code. So, not using the C API will hurt Lua performance.
> >
> > -- Roberto
> >
> 
> But Lua also has some overhead with calling into C, doesn't it? So
> some common operations are faster in pure Lua than in C? I'm sure I've
> heard that.

  But don't those "common operations" already call into C?

  Here's what I know:  

	Pure Lua in PUC-Lua is slow [1].
	Calling into a C function in PUC-Lua is faster.
	Calling into a C funciton in LuaJit is slow (but still faster than
		calling a C function in PUC-Lua)
	Calling into a C function in LuaJIT via the FFI is faster (because
		the JIT handles the binding automatically).
	Pure Lua in LuaJIT is (possibly) still faster.

  Just on a lark, I wrote two programs, one in pure Lua; the other one pure
C.  The programs calculate the Mandelbrot set (but don't output anything---I
wanted just the pure calculations) [2].  Here are some timings:

	Lua in PUC-Lua:	52.7s
	C:               2.7s (compiled with -O3)
	Lua in LuaJIT:   2.5s

  Now, given that the C version is *just* slightly slower than the LuaJIT
version (and really, it's the *same* Lua file run with both), I would
suspect that writing the main core with the C API would make the PUC-Lua
version faster and the LuaJIT version slower.

  -spc (But, as always, measure measure measure ... )

[1]	Relatively speaking.  Compared against, say, Python or Ruby, it's
	fast.

[2]	Code available upon request.