Author: Vincent Diepeveen
Date: 17:45:07 08/30/01
Go up one level in this thread
On August 30, 2001 at 13:56:53, Scott Gasch wrote: Some years ago i was faced with the same problems as you face now with. Without doubt the best solution for windows is what Andrew Dados suggests, the global thread variables. One small problem is that your program only works for windows then, and monsoon no longer works then under linux. You can slow down your program, bob is always a fan of that, as overhead doesn't need to be 400% of course. Bob estimates it at i think 10% or so? But by far the simplest solution to get rid of all these problems is to get multiprocessing. Whatever way you search parallel, multiprocessing is faster if you want to avoid all the tough global thread variable definitions! Also at the superb dual AMD SMP chipset there is no longer any disadvantage in multiprocessing. For BSD it even has more advantages, as bsd can only do multiprocessing, i heart multithreading might deliver problems under bsd at a multiprocessor machine. My tip go for a 0% overhead, and 0% problem thing and go multiprocessing. whether you multithread or singlethread, that hashtable you need to share anyway, so who cares? >I'm moving around data structures in my engine to consolodate things that are >going to be needed on a per-cpu basis if/when I go parallel. > >One such structure is my move stack. It's a big array of moves with a start and >end index per ply. So for example it might look like this: > >start[0] = 0 ... end[0] = 32 [array entries 0..32 hold moves at ply 0] >start[1] = 33 ... end[1] = 60 [array entries 33..60 hold moves at ply 1] >... > >Well if more than one thread is searching at once I will need more than one move >stack and more than one ply counter. So I kept the same move stack struct and >made g_MoveStack an array: > >MOVE_STACK g_MoveStack[NUM_CPU]; > >The code to access the move stack goes from this: > >g_MoveStack.iStart[g_iPly] = 0; > >to this: > >g_MoveStack[iCpuId].iStart[g_iPly[iCpuId]] = 0; > >Talk about a huge impact -- move move generator benchmark literally is 4x >slower! These dereferences are damn expensive. There has to be a better way, >can one of you assembly gurus give me a clue? > >Here is a solution I am thinking about -- have a struct per-thread that houses >the ply and a pointer to the start of the right move stack entry. Then do >something like this: > >THREAD_INFO *pThreadInfo = &(g_ThreadInfo[iCurrentThreadId]); >(pThreadInfo->pMoveStack)->iStart[sThreadInfo->iCpuId] = 0; > >I bet this is just as slow though... Any advice? > >Thanks, >Scott
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.