Author: Robert Hyatt
Date: 11:53:59 04/05/02
Go up one level in this thread
On April 05, 2002 at 13:05:28, Keith Evans wrote: >On April 05, 2002 at 00:41:19, Robert Hyatt wrote: > >> >>1. I am sure there is room for more parallelism in various parts of the >>chip, but remember that Hsu was a very good designer and (for example) his >>evaluation _was_ highly parallel in its hardware implementation... > >There are some big advantages that Hsu has... > >1. He's a good designer willing to dedicate 10 years of his life to this > project. > >2. He was designing full custom chips - so he could really use circuit > design techniques as opposed to logic design techniques > >3. Access to GMs, Ken Thompson,... > >The result this is that his designs will be quite efficient. > >But my hope was that we could learn from his mistakes. So if there is >any deficiency that you heard him complain about in his chips and can >publicly discuss, then that might be very beneficial for future design >efforts in this area. For instance in the next to last generation he >surely complained about his lack of repetition detection publicly. > >>2. Hashing would certainly help, particularly in endgames... It isn't as >>big a thing as some might suspect however, because it isn't easy to do a >>"hash move" in the move ordering stuff since there is no move ordering in >>the hardware except for MVV/LVA and other simple tricks... > >Here's where my ignorance may come shining through... > >In Marc Boule's move generator there is a way for software for force a >particular move to be made - there is no reason why an on-chip state machine >couldn't do the same. Couldn't you just force the move generator to make the >hash move first? We could implement a hash move stack which would keep track of >the hash move made (if any) so that during the remaining move generation we >wouldn't make it again after returning to the node. It would make it more complex. It is easier to design a finite state machine to use a finite-state-generator... first stuffing a specific move would be an interesting problem. And then disabling that move from ever being generated would be yet another interesting problem. You _could_ just search the move a second time (assuming it didn't cutoff the first time) and let the hash table handle it.. but that might tend to make you search extra stuff if that particular table entry didn't survive long enough... It is certainly doable, but if you read Hsu's description of the DB2 chips, he had to shrink the "pads" on the silicon to something smaller than the standard for the fab process he used, otherwise the chip didn't have enough room for the hardware he had... It _barely_ fit because of all the routing problems he had to work around, and even after that they had cross-coupling problems that required software work-arounds to prevent the hardware from producing bogus results... So I can see why he didn't try that. And I can see advantages in trying to do both hash (and killer) moves in hardware, if space is no problem... > >And idea of the top of your head about what implementing hash moves versus just >hash scores buys you? Or any recommendations for articles to read with a lot of >benchmarking information? This could be measured. I did this years ago but don't remember the results. In the middlegame, the hash move is more important than the hash scores. Most positions you probe don't use the scores anyway (in the middlegame) but the hash move gives greatly improved move ordering... In Crafty it would be possible to "break" HashProbe() so that it either only returns the hash move, or the hash score, to see which is more important... In the endgame I am sure the scores are far more important.. > >Regards, >Keith
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.