Author: Tom Kerrigan
Date: 09:04:47 04/07/00
Go up one level in this thread
On April 07, 2000 at 08:07:56, Robert Hyatt wrote: >>(another 5 cycles). So doing SEE takes 10/2=5 times as long. This ignores the >>fact that the SEE is probably much more expensive than 1 cycle, and the added >>complexity/time of saving the list of captures/SEE values and then sorting them. >Again, as I said, if I was designing a circuit to do a SEE, it would _still_ >be faster than software SEE. And it could include as much as we wanted in >terms of not overlooking pinned pieces or whatever... and _still_ run fast >enough that it would be totally unnoticable in a chess engine... IMHO of >course. I still disagree. Didn't DB do a quick evaluation in ~4 cycles? So going back to my example, the time to search 2/5 capture moves using MVV/LVA is: generate moves = 2 * 2 make moves = 1 * 2 eval = 2 * 8 => 22 cycles And if you use SEE: generate moves = 2 * 5 SEE = 5 * 5 make moves = 1 * 2 eval = 2 * 8 => 53 cycles So I bet SEE would slow the chip down by at least a factor of 2. I think that's pretty noticable. >Not when you read the details about the _last_ ASIC. They added kpk endgame >database to simply fill out the remainder of the chip... which sounds like >space wasn't a problem... especially considering they used under 50% of the >total eval hardware in the last version of DB, which suggests that he also added >a _lot_ of feature detection hardware that was also done just to fill out the >chip and was not used due to lack of time to test it. Possibly. The PKP database doesn't impress me very much because it can probably be extremely dense. I wouldn't be surprised if the move generator was larger than the database. -Tom
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.