Author: Robert Hyatt
Date: 07:37:18 08/19/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. Not exactly. creating a new lightweight process is not horribly slow. The join() operation is trivial. But that means you get to create another process for the next parallel task, which adds up over time. The "thread pool" idea is well-known, but adds more complexity while saving the thread creation overhead. I opted to go for max performance here, myself. It is certainly far easier to start off creating and destroying threads, and once that is working, then try to "save" them with the thread-pool idea later.. > >>>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? :) > For chess, blocking semaphores are horrible. The locks are ultra-short-duration, and blocking will kill performance. That's why I wrote the spin-lock macro from the second parallel version. Normal blocking mutex locks just won't cut it. >>>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. That should not happen. mmx registers are just like any other registers, they are not shared...
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.