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 up things a lot.
Apart from that, I did the same as you, creating the thread after the genmove and joining them at the end of the thinking time. Sylvain 2009/1/20 Isaac Deutsch <i...@gmx.ch> > 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 thinking, the threads build a normal UCT tree. At the > beginning, they allocate a > certain number of nodes (100'000 as of now) and delete the nodes when > thinking has finished. > > To add RAVE to this, each node would need up to size*size additional values > for RAVE. I thought about > allocating this memory when children are added (which seems logical to me), > and deleting it also at the end > of the thinking time. However, this seems (I don't have any data) *slow* to > me , to allocate up to ˜50 MB of > RAM every time, then destroying it again afterwards. > > 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 genmove. This would > allow them to only have to alloc/dealloc when the board size is changed. > > Regards, > Isaac > -- > Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: > http://www.gmx.net/de/go/multimessenger > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ >
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/