lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On 4/04/2011, at 11:34 PM, Luiz Henrique de Figueiredo wrote:
>> Would you care to explain how you can get the above to work?  I thought maybe you mean that inside the block, everything is temporary, but I'm not sure that would work.
> 
> Yes, I mean that inside the block, everything is temporary and stored
> in static vars in C. The complex C library would have 256 static
> pointers to hold temporary userdata, say allocated at the start in
> luaopen_complex. complex.enter would start using them instead of
> allocating new ones. The expressions in complex.eval would be evaluated
> as usual by Lua, but using the temporary userdata. However, complex.eval
> would duplicate the userdata corresponding to its arguments, using real
> allocation, so that they can be returned. I should have written
> 	val1, val2 = complex.eval(a * exp(i*z) + b, a*b+z)
> 
> complex.exit would clear the internal counter. Perhaps it is not needed
> and this can be done in complex.eval, but it seems clear to explicitly
> bracket blocks.

Thanks!  I stand corrected.

I was half thinking of the case where one would like to turn the vector operation a = b + c*d into 

for i = 1, length
  a[i] = b[i] + c*d[i]
end

and use scalar temporaries rather than vector temporaries, but I realise you're not talking about that.

Is the earlier thread "LuaJIT - Is ffi.alloca possible?" relevant, and to what extent are you better off generalising from your temporary complex array to a "fast bump allocator"? (I admit I'm way out of my depth here, but I'm trying to follow!).

As I understand it, you're wanting to avoid allocation and GC overhead (and doing so effectively), but as I probably misunderstand, a fast allocator and generational GC might do almost as well, with the advantage that offer the same benefits to all code.

Cheers,
Geoff