[computer-go] RAVE and memory allocation considerations
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 -- Pt! 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/
Re: [computer-go] RAVE and memory allocation considerations
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 genmove. This would allow them to only have to alloc/dealloc when the board size is changed. If your threads persist from move to move, you will save not only the expense of allocating and deallocating a large memory pool, but also the cost of creating new processes. On the other hand, you will need a quick method of clearing old information from previous nodes. Terry McIntyre terrymcint...@yahoo.com -- Libertarians Do It With Consent! ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
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 -- Pt! 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/
Re: [computer-go] RAVE and memory allocation considerations
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 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 -- Pt! 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/
