[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Drawing the line between speed and simplicity/elegance
- From: Sean Conner <sean@...>
- Date: Sat, 9 May 2015 20:53:20 -0400
It was thus said that the Great Rena once stated:
> On Sat, May 9, 2015 at 1:01 PM, Roberto Ierusalimschy
> <firstname.lastname@example.org> 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 .
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) . 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 ... )
 Relatively speaking. Compared against, say, Python or Ruby, it's
 Code available upon request.