[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: Garbage collection
- From: "Brownsword, Andrew" <ABrownswor@...>
- Date: Tue, 22 Oct 2002 08:59:49 -0700
The main issue is that the PS2 is a fairly low clock rate by today's standards, and it has a small L1 cache, no L2 cache, and the memory is high latency RamBus memory. Walking many data structures is therefore a rather expensive operation, and this is my single greatest point of concern about using Lua on this platform.
I'd haven't been following the discussions lately -- what is the current plan for GC in Lua 5, and when can we expect to see an implementation of it to test with? What are the caveats to the reference counting scheme David mentioned?
-----Original Message-----
From: David Bhowmik [mailto:david.bhowmik@creaturelabs.com]
Sent: Monday, October 21, 2002 6:00 AM
To: Multiple recipients of list
Subject: RE: Garbage collection
Thanks for your feedback Joshua. I have now written a patch for lua to turn
its garbage collection into a pseudo reference counting system, and this is
working swimingly. I was wondering what platforms your game was available
for because we are currently working on PC but are considering porting out
engine to the PS2 and XBox. Do you know how lua performs on these platforms?
Is there anything to watch out for?
Dave
-----Original Message-----
From: Joshua Jensen [mailto:jjensen@workspacewhiz.com]
Sent: 11 October 2002 17:44
To: Multiple recipients of list
Subject: RE: Garbage collection
> I am having trouble with Lua garbage collection. I am using
> Lua as an agent system for a real time game. Basically the
> mark and sweep system takes to long. Having a small threshold
> requires garbage collecting regularly, which means marking a
> lot of data regularly and cleaning up a little of it. The
> marking takes to long to do so regularly. Having a high
> threshold requires marking less regularly which is better but
> cleaning up loads of data in one sweep, which takes to long.
> There is no good balance here. Has anyone found a way around this?
Don't cause anything to allocate during the real-time.
Seriously.
It was the only way to ship Amped: Freestyle Snowboarding. No closures
could be generated on the fly. No tables could be generated on the fly.
No strings could be generated on the fly. The allocations were
identified, and pregenerated before the real-time ran.
So, instead of filling in myTable like this in the real-time:
myTable = {}
myTable.Var1 = 5
myTable.Var2 = "Hi"
myTable was made global, generated before the real-time loop, with all
the possible fields in place.
In other words, either make the necessary changes to your real-time Lua
codebase (by breakpointing the realloc function for Lua to determine
where memory allocations are), or don't count on using Lua during your
real-time. :(
-Josh