Re: Array performance with 2.0.0-beta10 versus git HEAD
- From: Mike Pall <mike-1208@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Tue, 28 Aug 2012 23:37:37 +0200
Peter Colberg wrote:
> Further the array can be passed directly to
> C functions, and the malloc'ed pointer is kept alive as an upvalue
> of the function passed to ffi.gc().
The finalizer function receives the object to be finalized as a
parameter (i.e. 'array'). So simply run ffi.C.free(array.data).
That avoids creating a new closure for every allocation.
> The plan is to implement core algorithms of a molecular simulation
> using OpenCL (on the GPU) or C (on the host) code, therefore the
> convenience of bound checking and 1-based indexing in the LuaJIT
> part should outweigh the performance penalty.
1-based indexing as a feature? How quaint!
> typedef struct vec3_array { vec3 *data; size_t size; } vec3_array;
Avoid size_t, unless you need it for interfacing to existing code.
Better use int.
Also, you could use a VLS to inline the allocation, that avoids
all of that ffi.gc() stuff:
typedef struct vec3_array { int size; vec3 data[?]; } vec3_array;
...
local array = vec3_array(size, size)
--Mike
Other related posts: