Re: Extract a list of keys from table

["Alexander Gladysh" <agladysh@...>]

On Sat, Jul 19, 2008 at 1:42 AM, Mike Pall <mikelu-0807@mike.de> wrote:
> Alexander Gladysh wrote:
>> 2. Plain C version in LuaJIT is slower than specialized 'generated'
>> one in plain Lua, but still faster than any of generic versions.

> Not surprising, since the Lua/C API transitions add some cost. And
> a general rule for VMs with JIT compilers is NOT to rewrite your
> code in C because the compiler cannot optimize "into" C functions.

Well, I was more surprised that the rest of tests are that much slower
than C with LuaJIT 1.x. (Okay, 'unpack' is hindered by table
allocation, I see.)

> This applies even more so to LuaJIT 2.x: calling an "unknown" C
> function inside a loop effectively disables JIT compilation for
> this loop. Here "unknown" means the JIT compiler has no idea about
> its potential side-effects (note that most of the standard library
> functions are of course "known" to the compiler).

Would be there a some way to specify such side-effects (or at least to
specify that specific C-function has none)? I guess, it is too much to
ask (for 2.x at least), and may be not needed at all, especially when
those C functions may be rewritten back to Lua to gain some speed. :-)
(I mean utility stuff like that extract_keys function.)

> But falling back to the interpreter is not so bad, since it's
> pretty fast (around the speed of LuaJIT 1.x). The "C" test takes
> 2.87s on a Core2 @ 2.13 GHz.

Great!

> All other tests run (or should run [*]) in around 0.0047s. :-)

> This is because everything can be hoisted out of the loop. The
> loop itself runs at 1 cycle/iteration, i.e. maximum CPU speed.
> The perils of microbenchmarking ...

Oh. Anyway, that is great to have one more proof that LuaJIT 2.x is that good.

But, may I adjust my benchmark to make it a bit less synthetic and
predictable? Maybe query a random set of keys instead of fixed one?
(Of course, do pregenerate a list of such sets, say 1024 of them, to
be queried in a loop -- so randomization would interfere less with
main test.)

> [*] Not all of them can be compiled (yet). Sorry, still no ETA.

Like Javier said, it just became harder to wait :-)

Alexander.