Mikko Aarnos wrote: > There is a big difference here: Ellis's program can only do light > playouts. He doesn't have MCTS or patterns. That is parallelized > extremely simply by just giving each thread an internal board state, > doing a playout from that, resetting the board state to the > original, doing a playout etc. There are no bottlenecks there, and > that shouldn't get any increase in performance from HT as far as I > know(also see the first sentence of Schmicker's comment).
I don't think that's right. I tried an experiment once with hyperthreading and 'light playouts' and I got a 40% improvement from using two threads per core. There are plenty of bottlenecks even in such simple code. For example, any time you do something equivalent to following a linked list (eg, finding the stones in a group that you're joining to another group) the thread will have to wait three or four cycles per 'link' even if all the data is in level-1 cache. One way to tell whether code is likely to benefit from hyperthreading is to use a tool that reports the processor's performance counters and look at the 'instructions per clock' measure. If it's somewhere around 1 then there are excellent chances of getting good results from hyperthreading. -M- _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
