Author: Scott Gasch
Date: 12:05:11 11/19/04
Go up one level in this thread
On November 18, 2004 at 22:40:48, Daniel Shawul wrote:
>On November 18, 2004 at 07:58:01, Anthony Cozzie wrote:
>
>>On November 18, 2004 at 07:36:58, Daniel Shawul wrote:
>>
>>>i have made a wrapper class for the lock/unlock operations
>>>that i do at a struct SPLIT.
>>>SPLIT
>>>{
>>> //HANDLE lock;
>>> CRITICAL_SECTION cs;
>>> other data...
>>>}
>>> At codeguru site i read that critical sections are faster than
>>>mutexes.But for me they are *very very slower*. I am sure i am doing something
>>>wrong but don't know what?
>>>Another question is how profitable is using methods like InterLockedExchange,
>>>i mean going low level, for SMP chess engines?
>>>
>>>SPLIT::SPLIT()
>>>{
>>> //lock = CreateMutex(NULL,0,NULL);
>>> InitializeCriticalSection(& cs);
>>>}
>>>SPLIT::~SPLIT()
>>>{
>>> //CloseHandle();
>>> DeleteCriticalSection(& cs);
>>>}
>>>SPLIT::Lock()
>>>{
>>> //WaitForSingleObject(lock,INFINITE);
>>> EnterCriticalSection(& cs);
>>>}
>>>SPLIT::UnLock()
>>>{
>>> //ReleaseMutex(lock);
>>> LeaveCriticalSection(& cs);
>>>}
>>>
>>>best
>>>daniel
>>
>>You want a spinlock, not a mutex/semaphore/criticalsection/other OS trick.
>>Split is supposed to be _cheap_. If you block on a critical section, the
>>processor may put your process into the idle queue and run something else.
>>
>>Read my other post. You need to spend a few weeks 1) looking over the Crafty
>>code 2) reading the DTS paper 3) _thinking_ about your design and how you want
>>it to work and under what circumstances (2? 4? 8? 500? processors). IMHO,
>>writing a parallel chess program is one of _the toughest_ programming tasks out
>>there, and you are seriously underestimating it. I spent probably 6 weeks just
>>designing - and I threw out at least 10 designs - before I settled on what I
>>have. Then I spent 2 weeks implementing, and I'm still working races out of the
>>system 6 months later (it crashes once every few days right now). And this is
>>on only two processors!
>>
> I am not underestimating parallel search. IMO it seems to me you are over-
>estimating it :) I have already finished implementing abdada,and another type of
>splitting that Scott Gasch described to me very well in email. He also gave me a
>lot of advice how I should do each thing step by step. However bad it is,i have
>something which can generate n threads in parallel and search in parallel.
>Problem is how to optimize it and that i will do in time.
>About studying crafty code, so far i haven't but someday i will when i want
>my parallel search to be more advanced.
>
>daniel
>p.s: your comment is really frustrating but..
>
>>anthony
Well here's my take on parallel programming: I had a lot of experience with
multithreaded programming (not in chess, just in work projects etc.) Now
whenever I would ask about making an engine search in parallel people would go
on about how hard it was -- i.e. it took me a year and was really tough etc...
Also I read a ton of papers about DTS, PVSplit, ABDADA, YBW, etc... Hearing how
hard it was and seeing all these papers with different results and approaches
caused me to procrastinate starting my MT engine for over a year... I wanted to
plan it all out, do it "right the first time", and make sure I had time in my
scheduled to devote to the N months of intensive work that this was gunna take.
In retrospect this was wasted time.
When I finally started it (after hearing another programmer tell me exactly what
I'm telling you in this message and the others in this thread) it took a couple
of weeks to redesign the engine to work in parallel (i.e. different move stacks
for different threads, pass the board around in search/eval, lock the hash table
etc). Then it took literally 3 days to get something that searched in parallel
badly. Yes there were bugs. Yes there was contention to work out. This stuff
took another week or two to work out. Then a week of tinkering with where
exactly to split, how to detect draws below splits, tricky stuff you didn't
think of in the first place.
I'm not trying to say MT search is easy. It's not; and the first step is you
need to understand multithreaded programming. What I'm trying to say is for a
programmer who has a handle on coding multiple threads, making your engine
search in parallel is probably not as hard as you think. It might take you a
month of real work but I'd be surprised if it took you a year. Don't let people
scare you off because it's really not that hard.
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.