Re: Extract a list of keys from table

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

Javier Guerra wrote:
> are you planning an API to "introduce" new functions to the JIT?

It's called "write them in Lua". :-)

But I guess you meant ...

Alexander Gladysh wrote:
> 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.)

Well, probably not for the first version. There are many
"interesting" constraints for the compiler (like not running the
GC or not writing to tables). But most of them cannnot be easily
applied without deeper knowledge of the VM (like which Lua/C API
calls may run the GC and which certainly won't).

Javier Guerra wrote:
> do you mean that LuaJIT 2.x realizes that the iterations 1-9999999 (or
> maybe iterations 2-10M) don't do any new work and executes only once?

Yes. The loop is pre-rolled once. This iteration contains both the
variant and the invariant parts. Then the 'real' loop follows
which only contains the variant parts. Since nothing in this
benchmark is variant (and none of the results are really used), it
executes an empty loop for the remaining N-1 iterations.

Alexander Gladysh wrote:
> 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.)

Then you may end up measuring the randomization or the fetching of
the sets. If you don't do anything with the results or calculate
anything meaningful you can still be outsmarted by the compiler in
many ways. It _is_ hard to write good benchmarks.

But I can save you time: I'd recommend the "generated" approach
because it's the easiest to compile, i.e. most likely to produce
the best code in a real application.

--Mike