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
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)


Other related posts: