Re: can someone explain why...

[Eike Decker <zet23t@...>]

> Anyway, as I'm writing an extension for an app, I've already
> code few things in C.... probably will write later this function in C too.
> But then, if I surely gain a lot of time with the 2 for loop being in C, what the
> cost of the overhead to call again and again this C function ?
> Or put it in another way,
> is the cost of calling a Lua function is the same as calling the equivalent C function ?

There is no simple way to answer that. Calling C functions is quite
cheap. It depends mostly on what your C function will do. Example for
number crunching with integers: Clean integer arithmetics are
(probably) much faster than the high precision floating point
operations in Lua. But don't forget: Converting floating point to
integer is a rather expensive operation and can eat up the gain easily
if you don't do much with the integers - so calling a C function when
doing integer operations can be slow if you waste most CPU cycles on
converting the numbers. On the contrary, Mike Pall has done quite a
lot for optimizing the floating point operations in LuaJIT and it's en
par with C code or even sometimes faster in a few cases, depending on
the used compilers for the C code and how well it optimizes the code
for floating point operations (as far as I have understood).
But C code will (most likely) always beat Lua code when it comes to
pure number crunching in static memory structures. You don't need
table allocations in C and you can maybe calculate the sizes ahead of
time, which helps a lot. The CPU will work such task off extremely
efficiently because it won't need to check GC code or anything else
while working. Your current function with the loops would run probably
much faster in C due to less memory management code that comes with
the Lua VM. Next to that, if you can avoid floating points and use
integers instead, you'll gain even more.

> Is there some guidances somewhere to know the good balance ?

Most often, you won't need C code to improve your performance. Most
CPU time in Applications is wasted on 5% of the code and that is the
code that is (maybe) worth to be moved into C. Maybe. I use Lua to
control the application and use C code in the hot spots. I find it
often also easier to apply clever ideas for optimizations in Lua code
(caching results, using complex dynamic data structures) than in C
code, so it's sometimes enough to rewrite the Lua code in question
using Lua. Clever ideas can often outrun brute force solutions (though
not always, because the O notation is not correct when it comes to the
actual costs on computer architectures). I prefer to use C in the
cases of simple brutal number crunching jobs (like iterating an array
of 1 million numbers and calculating stuff). For example, I wouldn't
implement a fourier transformation in Lua unless the speed doesn't
matter.

> And another question coming out of your answers :
> writing few functions like this one in C,
> is there still a gain to use LuaJIT then ?

Yes, most often, JIT will improve your general speed. If your
application spends however 95% of the time in C, it won't change
anything visible. But I would also suggest to provide your own memory
allocator for Lua - depending on what you do. I've once analyzed the
allocations of Lua in a game engine and most (>98%) of the allocs were
less than 200 bytes large. So I wrote a simple bucket allocator that
would handle allocations for up to 256 bytes (starting of 16 bytes I
think, allocating in sizes of power of 2, so 5 buckets having each
blocks for 16, 32, 64, 128 and 256 bytes) blocks and managing the free
blocks in simple linked lists - so allocations and free operations had
a theoretic cost of O(1) (whereas default malloc is much more
complex). The memory for the blocks was preallocated using malloc
(alocate 4MB ahead and allocate other 4 MB chunks if necessary) and
memory was not given back to the OS (like the free func would do
afaik). The speed improvement of that simple solution was really good,
and especially, it made the engine run much smoother because most
allocations had then mostly equal costs. You can of course combine
LuaJIT with your own allocator for an optimal result.

> Hope I'm clear ( sorry my mother tongue is French )

Don't worry. Neither is this my mother tongue.

Eike