Author: Anthony Cozzie
Date: 06:51:43 05/26/04
Go up one level in this thread
On May 25, 2004 at 21:33:32, Robert Hyatt wrote: >On May 25, 2004 at 19:52:56, Will Singleton wrote: > >>On May 25, 2004 at 17:33:12, Sean Empey wrote: >> >>>On May 25, 2004 at 17:09:02, Matthew Hull wrote: >>> >>>>On May 25, 2004 at 05:48:02, Sean Empey wrote: >>>> >>>>>No, it is not a clone of crafty. I will tell you that it does use Dan Corbit's >>>>>big book and crafty's book code, and the same egtb code that is used in crafty >>>>>18.15. Other than that not much else is from crafty. Oh some of the Print >>>>>functions I referenced are from crafty 16.x if memory serves correct. Storm is >>>>a >SMP engine and uses a completely different algorithm for its search eval. It >>>>>uses ABDADA.I have offered portions of code to Professor Hyatt but on the >>>>terms >it not be published or used by him or others. My move generator >>>>functions are >completely different and I can not go into detail regarding them >>>>as some of the >code came from a professional programmer (at least the >>>>approach) on the >condition I not release that code ever. Because a program has >>>>similar evals does >not make it a clone. If I wanted to clone crafty I would >>>>not have been working >on Storm for years; actually starting about one year >>>>before CCT1. As I have told >Professor Hyatt. I am not cloning crafty. We have >>>>talked and he is fine. Any >other questions someone may have; I'm willing to >>>>answer them to the best of my >ability. I would appreciate ad hominems and >>>>other unnecessary comments not be >made as I have stated I'm willing to back-up >>>>my claim. >>>> >>>>Hi Sean, >>>> >>>>A question about SMP. Does Storm use threads or processes when splitting the >>>>search? Which do you think is most effective? >>>>Thanks! >>>> >>> >>>I use ABDADA, which I learned from an ICCA publication. You can find info here: >>>http://www.recherche.enac.fr/~weill/publications.html >>> >>>There is no communication between threads. Just a shared hash table and it's >>>pretty easy to implement. I have been happy with it. It may not be the best for >>>SMP machines. Professor Hyatt says nothing beats a perfectly implemented PVS. He >>>may be right. >> >>Hi Sean, >> >>I'm like someday to do multiprocessing, but I haven't studied it. You indicate >>there's no communciation between threads, how does that work? I assume there's >>one thread that does i/o, and that thread must somehow inform the other what the >>position is and get search results. >> >>Also, I think I understand how two threads can share the same hash table, but >>how do you handle locking? Is it automatic or do you need to explicitly lock >>the memory while writing? And what kind of speedup do you get? Does the ICCA >>article use the same approach (shared hash, multiple processes, no comm)? >> >>Will > > >This is a _very_ primitive approach to parallel search. It will do fairly >reasonably with 2 processors. Go beyond that and performance becomes very >poor... > >It is one of those "easy to implement" approaches, but in this case you really >do get what you "pay for" and since you don't "pay very much in terms of >effort..." In the paper they quoted a 64X speedup on a 128 processor machine, which is pretty good I would think. It doesn't seem like it would perform that well after looking at the algorithm though. 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.