I made some tests: -Creation&joining of threads is almost free; on my system it takes about 0.003s to create&join 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 1/40-1/400 of the total thinking time). -when doing the same with nodes with rave values (I considered 1600 byte average each), it takes about 0.3s.
So indeed, it might be useful to keep a pool of the big nodes, but I wouldn't bother with smaller arrays. How do you think this pool should be made? I don't want the threads to step on each other's toes. :) Regards, Isaac -------- Original-Nachricht -------- > Datum: Tue, 20 Jan 2009 19:17:06 +0100 > Von: Sylvain Gelly <sylvain.ge...@m4x.org> > An: computer-go <computer-go@computer-go.org> > Betreff: Re: [computer-go] RAVE and memory allocation considerations > 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/ > > -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
