[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: matrix operations and temporary objects?
- From: Mark Hamburg <mark@...>
- Date: Fri, 7 Aug 2009 09:34:23 -0700
To make begin_computation/end_computation work, you essentially want
something like:
for n = 1, 1000 do
begin_computation()
m = m * m1 + m2
end_computation( m )
end
m1 and m2 are preserved because they don't get reallocated in the
loop. We signal preservation of m by passing it to end_computation.
This pattern is risky with respect to exceptions since the computation
can remain open longer than desired. The following variation suffers
from function call (specifically pcall) overhead but could fix that
problem:
local body = function() return m * m1 + m2 end
for n = 1, 1000 do
m = compute( body )
end
compute can know that it should preserve its results. (It could also
use the debug API to get it to preserve its upvalues.)
But now we're basically back to the situation with using strings or
some other mechanism to allow the code to be compiled differently. How
about the following form:
function computation( flush, m, m1, m2 )
for n = 1, 1000 do
m = m * m1 + m2
flush( m )
end
return m
end
m = run_computation( computation, m, m1, m2 )
run_computation adds an extra first argument which is a function which
flushes all newly allocated temporaries except the ones that get
handed to it.
Of course, any of these schemes are pretty bug prone since you are
doing essentially manual memory management but its non-obvious manual
memory management.
Using the debug library could mitigate that by having the flush
function actually be aware of the local variables and upvalues in the
computation.
On a related note, I keep speculating about whether it's worth the
effort and complexity to detect objects that don't gain non-stack
references and collect them immediately when their last stack
reference goes away. It's enough of a whack to the Lua implementation
and I lack sufficiently good benchmarks to judge the results that this
remains at the speculation phase. In any event, the model I've been
thinking about here wouldn't help you because I was only going to
collect at function boundaries.
Finally, something that would work if one is into patching Lua is to
use reference counting. Generally, the overhead isn't worth the
trouble, but it might not be in this case since rapid recycling of
memory is very useful. There used to be a reference counting patch for
Lua, but I don't know whether there is one for 5.1.4.
Mark