Re: Luajit and curstom data structures

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

KR wrote:
> However, I then tried the following alternatives which result in
> empty tables (so luajit should be able to avoid checking the
> hash part of the table as well, right?) but I keep getting
> inferior performance compared with direct access:

Ah, sorry. I forgot about a pending problem with empty proxy
tables. The interpreter always creates proxied keys in the hash
part, even if a metamethod is called (Lua has the same problem).
The values are nil of course, which makes it indistinguishable
from a truly empty hash table from the perspective of the user.
But it made the hash table non-empty from the perspective of the
JIT compiler.

I've fixed this problem in git HEAD. Thank you for the reminder!

> -- I think this one is preferable 
> local Vec = {}
> function Vec.new(n) 
>   local storage = ffi.new("double[?]", n) 
>   local ret = {}
>   -- {__index=storage, __newindex=storage} seems to works equally well...
>   setmetatable(ret, 
>   { __index = function(x, i) return storage[i] end
>   , __newindex = function(x, i, v) storage[i]=v end })
>   return ret
> end
> 
> local Vec2 = {}
> function Vec2.new(n) 
>   local mt = {}
>   mt.storage = ffi.new("double[?]", n)
>   mt.__index = function(x, i) return mt.storage[i] end
>   mt. __newindex = function(x, i, v) mt.storage[i]=v end
>   local ret = {}
>   setmetatable(ret, mt)
>   return ret
> end

These examples now run as fast as the direct cdata access.

But please note that you really don't want to create several new
closures and tables for each instance. So this is not an optimal
solution.

> -- For x vector or vector view
> y = x[i]
> x[i] = y 
> n = x:size() -- size(x) or x.size are fine alternatives
> n = #x -- same as x:size()
> n = x:stride() -- always 1 for vector but not for vector view (for instance if 
> it is the view of a column of a matrix)

You'll be able to do this with reasonable efficiency with the
planned metatables for cdata objects.

> I am a bit more worried about the x[row][col] syntax, but maybe
> it's doable as well if x[row] returns the "pointer" to the
> element shifted row positions downward with respect to the
> top-left element of the view which then gets shifted rightward
> col elements (sorry for the imprecise language, I hope you got
> the idea :P)

Actually the FFI library already uses exactly this approach for
indexing multi-dimensional arrays. Ditto for arrays of structs or
structs of arrays. The JIT compiler ought to be able to eliminate
the intermediate pointer objects (this may be difficult in some
use cases, though).

--Mike