Author: Robert Hyatt
Date: 07:02:50 05/14/99
Go up one level in this thread
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...
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.