Author: Bruce Cleaver
Date: 10:42:00 05/14/99
Go up one level in this thread
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... If I understand correctly, the DB eval function was very complex, perhaps far more computationally expensive than a Crafty or Rebel eval function. This might explain why DB supposedly crushed the micros at similar NPS (at 100knps,. if memory serves). Any info/thoughts on this?? Thanks, Bruce
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.