Author: Anthony Cozzie
Date: 11:31:47 06/16/04
Go up one level in this thread
On June 16, 2004 at 14:18:21, Eric Oldre wrote: >On June 16, 2004 at 10:34:20, Anthony Cozzie wrote: > > >> >>Here is what will happen (more or less, Operating Systems has never been my >>strongpoint): >> >>CPU Snapshot: >>Search thread - running >>IO Thread - blocked, and in the idle queue waiting on input >>Xboard - blocked, and in the idle queue waiting on a timer >> >>CPU gets timer interrupt >>CPU transfers control to OS >>OS notes that Xboard's waiting time has finished and gives it the CPU >> >>CPU Snapshot: >>Xboard - running >>IO Thread - blocked, waiting on input >>Search Thread - in the runqueue >> >>Xboard does its business and sends some command to your engine. It then >>finishes. >>The OS notes that the IO thread now has data (its call can return) and transfers >>it to the runqueue. >>The OS's Scheduler then selects the IO thread over the Search thread because the >>IO thread has been blocked longer. >> >>CPU Snapshot: >>IO Thread - running >>Search Thread - in runqueue >>Xboard - blocked, waiting on timer >> >>At this point I think you have some idea of what is going on. >> >>One suggestion, if you are intent on doing threads. The problem with the IO >>thread is that it must receive commands from two places: the search thread and >>Xboard. This creates some very nasty issues to work out. >> >>Parallel programming is tough. Write out your implementation *thoroughly* on >>paper. Think up the most *annoying* circumstances possible: What if the IO >>thread gets a ping+move now+abort command sequence while the search thread sends >>a game_over command? Parallel programming is very difficult to debug because it >>is nondeterministic: you might run the program again and the error won't occur. >>Most importantly: MAKE SURE YOU RUN ON A MULTIPROCESSOR MACHINE. Hyperthreaded >>P4s are common enough that this shouldn't be that hard. My first two threaded >>implementations both worked fine on single processor machines, but broke down >>completely on an MT machine. My 3rd parallel implemenation worked on MP >>machines, but had a few race conditions that only appeared in bullet. >> >>I'm in sort of the same boat right now, as I'm trying to write a parallel search >>implementation, which is just as annoying and about 50000x harder :( >> >>anthony > > > >Anthony, >thanks, that was a good description for me to get a handle on how things would >work. > >I'm probably getting WAY ahead of myself, but I too would like to someday be >able to support parallel searching. which is part of what is leading me to want >to go the multi-threaded approach, this way i'd at least begin to get a handle >on some of the techniques i'll need at that point. But your warnings are >definately making me think twice about it. That was one of my thoughts as well. About two years ago ;) >currently my only machine is a amd64 3200+, which of course is not mp. but i'm >considering buying a new laptop, Which could be a hyper-threaded P4 and then be >used for testing MP techniques. Do you know if the pentium M line uses HT >technology? No. It does not. >Are there any specific issues you came across on the MP machine that didn't on >the Single processor? > >Eric If you want to learn about threaded programming, then I guess this is a good a task as any. The MP machine will have a larger number of race conditions that can occur, because in a single CPU machine only one of the threads will be running at any given time. Also, I should say that I was very new to parallel programming when I did my first implementation. If I had to design it from scratch now, I doubt I would need 4 tries :) anthony
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.