[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaJIT with vectors
- From: Mike Pall <mikelu-1011@...>
- Date: Thu, 18 Nov 2010 17:17:48 +0100
Petri Häkkinen wrote:
> Would it help if I counted how many temp vectors a real commercial game
> written in C++ does each frame? Is there any other statistics that would
> help in estimating the impact?
This would certainly be an interesting number to know. Please do!
But such a number says little about how many of the allocations
the compiler could optimize away. For that, I'd need to see the
actual code for the top allocation sites (the whole call chain
where the vectors are passed). Abstract code that only shows the
data-flow would suffice.
> Ok, too bad. But this can't mean that it's impossible to have values with
> different memory footprints in a dynamic language, does it?
Think about it that way: it requires an indirection in any case.
But this is not much of an issue. Also, it doesn't matter whether
it points to memory on the heap or the stack or wherever.
The real issue is how and when to dispose of or recycle the memory
that holds the oversized values. The traditional approach in
memory-safe languages is to use allocation/GC. Holding values in
the stack is not memory-safe, unless you can prove these values
can never escape. The same logic applies, whether it's on the C
stack or some kind of auxiliary part of the Lua value stack that
gets cleaned up on return.
So eliminating the allocation requires escape analysis, anyway.
Ditto for store sinking + allocation sinking, which is strictly
more powerful (this works, even when the value escapes only in
some uncommonly executed part of the code). I'm aiming for the
latter, but this will take a lot of time to design and implement
(maybe after the next beta release).