Author: Eugene Nalimov
Date: 12:32:54 05/14/99
Go up one level in this thread
On May 14, 1999 at 15:11:07, Dave Gomboc wrote: >On May 14, 1999 at 13:38:04, Dave Gomboc wrote: > >>On May 14, 1999 at 13:21:55, Eugene Nalimov wrote: >> >>>On May 14, 1999 at 12:26:19, Dave Gomboc wrote: >>> >>>>On May 14, 1999 at 11:05:06, Albert Silver wrote: >>>> >>>>>On May 14, 1999 at 10:02:50, Robert Hyatt wrote: >>>>> >>>>>>On May 13, 1999 at 23:49:59, Albert Silver wrote: >>>>>> >>>>>>>On May 13, 1999 at 22:18:59, Robert Hyatt wrote: >>>>>>> >>>>>>>>On May 13, 1999 at 09:58:12, Robert Pope wrote: >>>>>>>> >>>>>>>>>On May 13, 1999 at 09:14:48, Robert Hyatt wrote: >>>>>>>>> >>>>>>>>>>On May 13, 1999 at 09:10:05, Torstein Hall wrote: >>>>>>>>>> >>>>>>>>>>>I think a DB chip will kill all the Fritzes, Rebels, Nimzos, Juniors and Hiarcs >>>>>>>>>>>of this world. What is the point in developing, or buying, something that is a >>>>>>>>>>>lot weaker than the "Micro Monster" :-) >>>>>>>>>>> >>>>>>>>>>>But perhaps it could be made with a programming interface, letting other >>>>>>>>>>>programs use it for search, and add their own evaluation functions etc.? >>>>>>>>>>> >>>>>>>>>>>Torstein >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>This can't be done... the _hardware_ does the eval, and the last N plies >>>>>>>>>>of the tree search. All that could be modified would be the first few plies >>>>>>>>>>of the search, (and the extensions) since that part is done in software. But >>>>>>>>>>the "guts" of the thing will _always_ be deep blue. It can only evaluate the >>>>>>>>>>things that the hardware was built to do, and no more. The search and >>>>>>>>>>quiescence search can only behave like the chip is built with no flexibility. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>Evaluation weights can be changed, but new things can't be added... so no >>>>>>>>>>matter what you do, you end up with a 'deep blue' program... >>>>>>>>>> >>>>>>>>>>Bob >>>>>>>>> >>>>>>>>>In theory, though, how feasible might it be for Hsu to create a modified DB >>>>>>>>>"searcher" chip that just did the make/unmake part of the search? When it gets >>>>>>>>>to the eval part, instead of the lightning-fast hardware eval, it sends out >>>>>>>>>current position information, and waits for a software eval to be returned. I >>>>>>>>>know a software eval would cause a huge performance hit, but wouldn't the faster >>>>>>>>>move generation and tree travel still give it a nice advantage over a pure >>>>>>>>>software program? >>>>>>>>> >>>>>>>>>I remember the article mentioned something about a hardware trap-door in the >>>>>>>>>chip that could potentially be used to add a missed eval feature to the search. >>>>>>>>>It seems like that idea ought to be extendable to adding a software evaluation >>>>>>>>>or evaluation supplement. >>>>>>>>> >>>>>>>>>Rob >>>>>>>> >>>>>>>>This would make no sense to do... IE the speed of the thing comes from the >>>>>>>>hardware search _and_ hardware eval. Take the eval to software and you lose >>>>>>>>_everything_. IE in crafty, Make/UnMake account for well under 20% of the total >>>>>>>>search time. Doing that in hardware would hardly make me any faster at all. >>>>>>> >>>>>>>This does bring to light another question: would Hsu be planning (though this is >>>>>>>tremendously speculative at this point) on ever improving on the actual DB >>>>>>>program? Or would improvements, if any, only come in the hardware area? i.e. >>>>>>>Improving speed. >>>>>>> >>>>>>> Albert Silver >>>>>> >>>>>> >>>>>>I would see no reason why the "chip" wouldn't track hardware advancements. IE >>>>>>every couple of years, it would double in speed. And then there is the issue of >>>>>>'tuning the evaluation' since the evaluation 'weights' are all 'soft' and are >>>>>>modifiable... >>>>> >>>>>What I meant was, would Hsu bring in new knowledge to the program, or modify >>>>>existing algorithms, or would he be leaving it as is, and merely (nothing wrong >>>>>with this, just curious) fine-tune the eval and keep the chip's technology up to >>>>>the ever newer standards? I would be very curious to see DB using Alpha-Beta >>>>>though I don't know how big a change that would imply. As I recall, you said >>>>>that Hsu abhored any kind of shortcuts that might give cause to an oversight. >>>>> >>>>> Albert Silver >>>> >>>>Alpha-beta wouldn't cause any oversights that minimax would catch. I would be >>>>extremely surprised if he did not include alpha-beta on it already. >>>> >>>>Dave >>> >>>According to the IEEE Micro article (sorry, not it's not near me right now, so >>>all data is from memory), they use only one bound, not two as "standard" >>>alpha-beta. That means that they use some variant of pv-search/mtd(f). >>> >>>Eugene >> >>I think they did use mtd(f). Maybe I will ask Jonathan (Schaeffer). >> >>Dave > >I asked him, he says no, that isn't the case. Apparently Hsu gets better >parallel speedup by using only one bound, even though his search tree is larger >than it would be if he used two bounds. > >Dave I beleive the problem is not better speedup, but amount of silicon necessary for keeping both bounds. And in a majority of cases (after we have the PV) the second bound is unnecessary anyway. Eugene
This page took 0.01 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.