[gambit-list] Garbage Collection BlackMagic

lowly coder lowlycoder at huoyanjinjing.com
Tue Jun 23 02:53:30 EDT 2009


Does Gambit have a counter for "number of live, non-still objects?"
Essentially this is what I need to minimize now, and being able to benchmark
it will be helpful.

Thanks!

On Sun, Jun 14, 2009 at 7:19 AM, Marc Feeley <feeley at iro.umontreal.ca>wrote:

>
> On 14-Jun-09, at 9:35 AM, lowly coder wrote:
>
>  In the code running at 100fps, I do a minimal amount of allocating. It's
>> practiaclly:
>>
>> (vector-for-map *some-vec* draw-object)
>>
>> (define (draw-object x)
>>  (call some gl-rotate / gl-translate)
>>  (gl/CallList x))
>>
>>
>> However, I do have  _ALOT_ of static data lying around. In fact, I have
>> large geometric models (from which I derive the open gl display lists) lying
>> around in memory. They're vectors of lists / other vectors / other lists /
>> ... of points / quads.
>>
>> This data also doesn't change, except at _very_ predefined locations.
>>
>> I guess if I can do somethign like:
>>
>> (##gc)
>> ( somehow tell gambit that the data currently left over is mostly static?
>> )
>>
>> ... continue running ...
>>
>>
>> That sould be ideal.
>>
>> why does vector vs list mater much for ##still-copy ?
>>
>> Thanks!
>>
>
> Are you using plain Scheme vectors to store your numeric data?  Here it
> will pay off to use f32vectors, f64vectors or any homogeneous numerical
> vectors.  That's because the content of these vectors are not scanned by the
> garbage collector.  As I said in a previous message, if these vectors are
> still objects they will not be moved by the garbage collector, which further
> reduces the time needed.  You can force an object to be still by passing it
> to ##still-copy.  For example:
>
> > (define v (f32vector 1. 2. 3.))
> > (define v2 (##still-copy v))
> > (list v v2)
> (#f32(1. 2. 3.) #f32(1. 2. 3.))
> > (##still-copy (list 1 2 3))
> (1 2 3)
>
> Note that in the last call to ##still-copy, a still copy is only created
> for the pair at the head of the list.  In other words ##still-copy does a
> shallow copy.  If you want a deep copy you have to code it yourself.  That's
> why David said ##still-copy is less useful for lists.
>
> An alternative is to store the data as C data, and use the FFI to access
> it.  The difficulty level will depend on the data and how you manipulate it.
>
> If you want to allocate "constant Scheme data" the only option right now is
> to create a Scheme file like:
>
> (define my-constant-data '#f32(1.0 2.0 3.0))
>
> then compile the file with gsc and load the object file into your running
> application.
>
> I'm working on a solution for allocating constant data at run time, but it
> is low on my TODO list.
>
> Marc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20090622/523cd576/attachment.htm>


More information about the Gambit-list mailing list