[computer-go] RAVE and memory allocation considerations

2009-01-20 Thread Isaac Deutsch
Thanks again for your pseudo-implementation, Sylvain. At the moment I have a program that uses plain MCTS. With every genmove, it creates a certain number of threads (2), gives them some starting data, and lets them think for a while, then rejoins them, extracting the best move. During the

Re: [computer-go] RAVE and memory allocation considerations

2009-01-20 Thread terry mcintyre
From: Isaac Deutsch i...@gmx.ch Do you think the spent allocating could be critical? What do you think would be a good way to deal with this? I think to avoid the continuous allocation/deallocation, it's necessary to keep the threads running instead of creating/joining them for each

Re: [computer-go] RAVE and memory allocation considerations

2009-01-20 Thread Sylvain Gelly
Hi, You should really look into never deallocate memory (by calling delete/free) but keeping it in some memory pool. I did that for the main objects that you deal with: nodes and small vectors (the one you create on the fly to keep the moves that have been played in the playout). It really speeds

Re: [computer-go] RAVE and memory allocation considerations

2009-01-20 Thread Isaac Deutsch
I made some tests: -Creationjoining of threads is almost free; on my system it takes about 0.003s to createjoin 8 threads. -when allocating, writing to and deallocating 100'000 nodes without RAVE values (about 25 byte each), it takes about 0.025s (almost free considering this is about