Re: Native Complex numbers for LuaJIT-2 [was Re: Benchmark shootout shows LuaJIT 2.0]

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

Leo Razoumov wrote:
> Does it mean that if I use lua_getfield(L, LUA_REGISTRYINDEX, tname)
> in my implementation of __add(z1,z2) the hash lookup will be cached
> for further invocation??

Your C side implementation doesn't matter that much. You _also_
need to add a recording handler to the JIT compiler. What you do
there _does_ matter. If you emit the correct lookups, they can
usually be hoisted.

To get some idea of it, look at (say) setmetatable(). Check the C
side of it in lib_base.c and then compare with recff_setmetatable
in lj_record.c.

> In general, how effective is LuaJIT-2 in minimizing run-time type
> identification overhead? Is there LuaJIT-way different from
> (interpreted) Lua-way?

It's quite effective. There is no way I could explain all of this
in two sentences. The FAQ has some links to papers on the subject.

Or have a look at the output of -jdump for simple example loops.
Then look into the LJ2 sources how it's done.

> Are there any common Lua idioms *not* recommended when writing Lua
> code and C-bindings targeting LuaJIT?

Just writing a C-binding doesn't help. A call to an arbitrary,
non-analyzable C function is not compiled at all right now. Even
if I'll add that later, most optimizations would not be safe to
use then. It would be slow, no matter what the compiler does.
A future FFI with hints about side-effects may help somewhat.

If you strive for a deeper embedding, you need to add functions to
the core libraries, add recording handlers etc. Probably doable
and even useful for the mentioned Complex data type. But not so
useful for arbitrary C functions.

Summary: Write more code in Lua -- LuaJIT 2.0 is fast enough.
         Reserve C code only for I/O and such.

--Mike