RE: Access C env per LUA instance
- From: Dibyendu Majumdar <dibyendu.majumdar@xxxxxxxx>
- To: "luajit@xxxxxxxxxxxxx" <luajit@xxxxxxxxxxxxx>
- Date: Tue, 29 Oct 2013 23:59:49 +0000
Mike wrote:
> If you need top performance and you're calling lots of C functions,
> then you need to switch from the classic Lua/C API to the FFI.
> But this implies you cannot get at the lua_State pointer from a C
> function called by the FFI, anyway. So I wouldn't bother with any
> temporary workarounds that mess with the lua_State or such.
Ok understood.
> For the FFI approach there are two solutions:
>
> a) Do it on the C side: use one of the faster thread-local storage
> (TLS) APIs, i.e. one that doesn't call a function for every TLS
> access. The optimum is a mov reg, fs:[fixed_tls_offset]. How to
> achieve that is different for every OS and C compiler.
>
I have been looking at using thread local storage. However, don't know enough
about how TLS is implemented to work out which API is best.
> b) Classic OO approach: pass a context argument to every function.
> If the context is (say) a pointer or an integer in an immutable
> upvalue then the JIT compiler will inline that as a constant for
> each C call.
>
Thanks - this seems easiest ... I will try this.
I have another question.
As I need to call the LUA functions many times from the C code - I am doing
this:
I am calling a LUA function to pre-compute values where possible and create a
closure with the bare minimum steps.
Then I store the closure in the registry by calling:
luaL_ref(L, LUA_REGISTRYINDEX);
Subsequently I execute the closure by calling it from C code - this is done
many times ... and the operations performed by the closure are numeric.
I am hoping that the closure will be JITed first time and then execute at
native speed later ... is that a correct assumption?
Regards
Other related posts:
