RE: Vectors/Atomic Tuples/Garbage Collection

["Nick Trout" <nick@...>]

> From: Dylan Cuthbert [mailto:dylan@q-games.com]
> > Also I do avoid creating tables (avoid, but not completly disallow)
> > during normal operation, I have been able to keep my garbage
generation
> > relatively modest so far.
> 
> It seems like you're trying to fight a tsunami with a feather as the
> complexity and number of your tasks increase though.  The problem is,
> unless
> the garbage collector is very smart its going to have to go through
pretty
> much every single object in existance checking its reference count,
when a
> few quick checks after an expression would solve the problem.  Going
> through
> every object at the end of every frame seems to be a major amount of
> overhead.  Of course, the garbage collector might not be as naive as
this,
> I
> haven't analysed that part of Lua yet.

Lua is going to have a generational GC. IIRC 70-80% of objects that are
collected are recent (perhaps temporary objects). Generational
collectors take account of age and can check more recent objects more
regularly without having to trawl over the entire object set every GC.
Lua is planning to have a incremental generational collector which will
spread traversal over several frames.

Allocating and collecting temporary objects through a special Lua type
and a change in the VM might be a solution but it really comes down to
how efficient the GC is and also how efficient your allocator and
deallocator is. There are systems (e.g. I think dmalloc) which cache
recently free'd objects for quick reallocation, so this combined with an
efficient generational collector is effectively like having temporary
variables.

See:	http://lua-users.org/wiki/MemoryAllocation


DC> With heavy user data when I do position = vector, a reference is
taken,
> right, when I modify it a copy is taken (via those Vector calls).  How
and
> when is the memory freed?  If this user data is a C++ class do I still
> have
> to use malloc/free with a positional new?
> I can imagine there being a whole ton of temporary 12-16 byte vectors
(not
> including the overheads on the Lua side for methods and metatables)
being
> malloced, I mean an *absolutely friggin' huge* amount as the game
> progresses
> frame to frame - these are only destroyed when the time-consuming
garbage
> collector is run, right?  (something you don't want to run whilst the
game
> is running or you might drop a frame)

Avoid creating objects. 


> frog = Vector{ 10, 20, 30 } + Vector{ 20, 30, 40 } + Vector{ 30, 40,
50 }
> 
> Are 3 Vector userdata (or table) objects created and not deleted until
the
> garbage collector runs?

Yes. I suggested a technique for reusing objects in a previous mail
which may also help alleviate this problem. 

Sounds like you want to have Vectors as userdata and perhaps in
interface like (add() returns self):

	Frog:add(10, 20, 30):add( 20, 30, 40 ):add( 30, 40, 50 )

Avoid creating lots of objects. You're right, you have to think about
what you're doing in order to make the language perform efficiently. You
can control the way that the scripters work by restricting the API and
documenting problems to avoid. Lua doesn't compile into machine code,
you have to try and get the best out of the VM. C++ can be very
inefficient and until clever blokes like you came along and wrote vector
template classes it was a lot harder to write efficient vector code.

One thing I found useful is looking at the Lua VM disassembly. I wrote a
script to merge VM code and source:

	http://lua-users.org/wiki/VmMerge

Sometimes you create objects when you don't realize it, like perhaps
when you're learning programming and you don't realize how expensive
passing structures by value is when it's not necessary or where you're
doing it, perhaps using unnecessary constructors.

--nick