The JIT compiler being enabled drastically affects FFI performance from
what I can tell; you should try a -jdump to make sure you aren't dropping
back to interpreted mode somewhere critical.
On Thu, Apr 16, 2015 at 8:24 PM, Sean Dunn <dmarc-noreply@xxxxxxxxxxxxx>
wrote:
So I boiled this down to a simpler test (snippet at
https://gist.github.com/anonymous/1259e1c8b82f1b91f30b )
For 1,000,000 function calls to functions with 1, 2, and 3 arguments, I
got the following times. 'Check' is a value sanity check, and 'Delta' is
the estimation of nanosec per function call. This is on a 2.66GHz Intel
Core2 Duo. (Although the sample code says it's using
std::chrono::high_resolution_clock, it's actually using
QueryPerformanceCounter)
Native time: 7186 microsec. Delta: 2.39533 nanosec. Check: 48569
LuaJIT C binding time: 143910 microsec. Delta: 47.97 nanosec. Check:
48569
LuaJIT FFI binding time: 41082 microsec. Delta: 13.694 nanosec.
Check: 48569
The FFI binding vs C binding ratio is a more in line with what I thought
it would be. FFI is pretty slow compared to native calls, but I don't know
if this has more to do with the JIT compiler than the cost per call. Is
there something I've done wrong in the Lua code to make the JIT compiler
function less than optimally?
(PS - Hey SNichols, nice to see you on here)
On Apr 16, 2015, at 10:00 AM, Stephen Nichols <snichols@xxxxxxxxxxxxx>
wrote:
Yeah. No guarantee that FFI is faster.
You sure your code path is being compiled? Got any test code to share?
steve
Sent from my iPhone
On Apr 16, 2015, at 9:44 AM, Sean Dunn (Redacted sender "
seanedunn@xxxxxxxxx" for DMARC) <dmarc-noreply@xxxxxxxxxxxxx> wrote:
I'm binding LuaJIT to a C library, and testing the performance of FFI C
calls vs normal Lua-style C bindings. I had always assumed FFI calls were a
great multiple faster, but what I'm seeing is much less so, and I'm asking
for a sanity check on my expectations.
My baseline is calling a selection of trivial (but not empty) functions
natively in C over a high number of repetitions, then comparing the same
loop in Lua via FFI and then via normal C binding calls. Here's what I'm
seeing (Win32 Release, static LuaJIT):
Native: 100%
LuaJIT FFI: 125%
Lua C Binding: 156%
Of course this means that the normal C binding calls are taking 125% the
time of LuaJIT FFI calls, which makes me think that either I'm testing this
incorrectly, or my expectations need to be reset. I would also expect there
to be a lot less overhead than 25% between LuaJIT FFI calls and native
calls. I'd expect less than 1%, because it's a direct call and the loop
iteration overhead shouldn't be great.
I haven't found any documented performance comparisons between native,
FFI, and and Lua C bindings (besides the comparison at
http://luajit.org/ext_ffi.html). I'd greatly appreciate if someone could
point me to a link, or maybe share some anecdata of your experiences with
this.
Thanks,
Sean
