Author: Gerd Isenberg
Date: 13:51:55 08/18/03
Go up one level in this thread
On August 18, 2003 at 16:24:09, Sune Fischer wrote: >On August 18, 2003 at 16:15:55, Russell Reagan wrote: > >>On August 18, 2003 at 16:02:41, Sune Fischer wrote: >> >>>Not exactly. >>>I clone the board and spilt the tree, as you would when you're about to set off >>>a new thread, this now works in perft. >>> >>>That's as far as I've gotten (wohoo:). >>> >>>Next up is the fun stuff, getting threads to spin and waking them up for a >>>search (no idea how to do this yet!). >> >>Hmm, I'm not exactly sure I understand how you're doing things. What do you mean >>by "split the tree, as you would when you're about to set off a new thread"? And >>from "getting threads to spin and waking them up for a search" sounds like >>you're creating some threads for searching and leaving them in either a >>suspended state, or a running state whenever the time comes. >> >>I've never implemented SMP search in a chess program (yet), but I've used >>threads some, and I would think it would be better to just start a new thread >>each time you want to start a new search (when it becomes your move, or when you >>want to ponder, or whatever). I think this is simpler than trying to manage >>threads and control their state. You can create a simple wrapper class to do >>this stuff and make starting threads, stopping them, and pausing them nice and >>simple. Hopefully I don't underestimate the cost of starting up new threads. > >If I cared about simplicity I would not be going parallel, I want performance! >:) > >From Crafty: >/* >******************************************************************************** >* * >* ThreadWait() is the idle loop for the N threads that are created at the * >* beginning when Crafty searches. threads are "parked" here waiting on a * >* pointer to something they should search (a parameter block built in the * >* function Thread() in this case. when this pointer becomes non-zero, each * >* thread "parked" here will immediately call SearchSMP() and begin the * >* parallel search as directed. * >* * >******************************************************************************** >*/ > >I take it this implies creating and joining is not efficient. > >>>I guess I also have to become somewhat of an expert of mutex'es, oh well. >> >>You don't have to get this complex if you don't need it. For instance, there are >>some "atomic" instructions/functions that you can use in Windows. You can look >>them up on Microsoft's website: http://msdn.microsoft.com. Search for something >>like InterlockedExchange, InterlockedCompareAndExchange, and stuff like that. >> >>These are functions to do some simple things like assignment, conditional >>assignment, and a few others (maybe 4 or 5 functions total), and you can do >>things like set flags and stuff like that, which may be all you need. Basically >>they let you work with simple variables in a thread safe way. If you need more >>than that, you might need to get into critical sections, mutexes, and >>semaphores...oh the joys of multi-threading! > >Yes this is what I need, do you think I want to be stuck in windows forever? :) > >>>Just got thinking, Gerd's assembler isn't thread-safe, is it? >> >>If you're referring to the MMX stuff, I'd guess not, since each thread would >>probably just trash whatever the other thread was doing in the mmx registers. > >Yeah I feared this. The registers are sort of like global variables, I guess >locking and unlocking registers is not an option. > >-S. These registers (MMX (Athlon/Opteron/P4) and XMM (Opetron/P4) may even used in reentrant float arithmetic and should be saved and restored before/after a context switch of current and future operating systems. I guess FXSAVE/FXRSTOR instructions are for that purpose. Gerd
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.