Hallo,
I have been profiling my Reversi AI and got some good speed ups. Now a large part of my running time is spent in a function called mark_array, in mem.c. It seems to be part of the garbage collector. I already allocate a large heap when the Gambit runtime is started, is there another way to call this function not so many times?
Cheers,
Afficher les réponses par date
Play with the lLIVEPERCENT option (you can trade off memory against cpu).
Also, you can try to lessen the amount of memory allocations. Make sure that for floating point calculations you're using the fl... operations and that you use the flonum and not safe declarations in those parts of the code; and/or instead of allocating temporary objects always freshly, reuse them and mutate their contents. Also if your allocations are mostly closures, play with the linining-limit, and avoid passing closures to other compilation units (instead put the called code into the same unit).
Hallo,
On 11/6/09, Christian Jaeger chrjae@gmail.com wrote:
Also, you can try to lessen the amount of memory allocations. Make sure that for floating point calculations you're using the fl... operations and that you use the flonum and not safe declarations in those parts of the code; and/or instead of allocating temporary objects always freshly, reuse them and mutate their contents. Also if your allocations are mostly closures, play with the linining-limit, and avoid passing closures to other compilation units (instead put the called code into the same unit).
Thanks for all the tips! Actually the allocations are mostly due to creating 64-bit integers, which are bignums. Those are the keys calculated from game positions, used in the hash table. I guess I'll implement the transposition table and related functions in C, it will cut garbage collection time (and hash calculation time) to a minimum.
Cheers,
On 2009-11-06, at 9:14 AM, Alex Queiroz wrote:
Hallo,
On 11/6/09, Christian Jaeger chrjae@gmail.com wrote:
Also, you can try to lessen the amount of memory allocations. Make sure that for floating point calculations you're using the fl... operations and that you use the flonum and not safe declarations in those parts of the code; and/or instead of allocating temporary objects always freshly, reuse them and mutate their contents. Also if your allocations are mostly closures, play with the linining-limit, and avoid passing closures to other compilation units (instead put the called code into the same unit).
Thanks for all the tips! Actually the allocations are mostly dueto creating 64-bit integers, which are bignums. Those are the keys calculated from game positions, used in the hash table. I guess I'll implement the transposition table and related functions in C, it will cut garbage collection time (and hash calculation time) to a minimum.
Did you consider using a smaller hash that can fit in a fixnum?
Marc
Hallo,
On 11/6/09, Marc Feeley feeley@iro.umontreal.ca wrote:
Did you consider using a smaller hash that can fit in a fixnum?
This hash is used, instead of the whole position (game board, who's to play etc.), as the key in the table, because of memory constraints. With 30-bit fixnums the hash cannot be used as the key, as the chance of collisions is too high.
Cheers,
-
Alex Queiroz -
Christian Jaeger -
Marc Feeley