flopnflush wrote:
fraction wrote:
Each thread churns through X number of CS game trees (which means threads can collide).
What do you mean here? Does each thread operate on a different part of your game tree. Or do they all perform parallel full chance sampled tree traversals? And if so, do you synchronize something?
Parellel full chance sampled traversals. It's synchronised on regret updates. I'm fairly certain it's not purely a synchronisation problem though - To checkl I've made (unsafe) unsynchronised code with non-volaitile member variables and there's no improvement in speed.
Quote:
I'm also using Java and I'm also trying to figure out the best options for multithreading for my cs cfrm implementation. I would like to know if it could screw up the algorithm if the regrets and average strategies are not updated atomically.
If the algorithm still converges if some values are sometimes not updated correctly, it would probably be the best option to let each thread do independent chance-sampled tree-walks without synchronization. Then we might still need to use the "volatile" keyword, but I'm not sure about that. Can anyone explain to me what exactly the "volatile" keyword does? My understanding is, that it prevents caching so that every thread always reads and writes the actual values directly from and to ram.
Yup, volatile means that if one thread writes to a variable then it's updated for all threads (which might be on other cores) straight away.
I'm trying to work out how to make the threads independent of each other but the only way I can do it would mean each having it's own copy of the information sets. I need some algo that will allow me to split them up between threads.
Login
Register
FAQ
Search
