rskrueger at jtmd.com
Mon Oct 27 12:50:18 EST 1997
> I dont know how serious this I/O disadvantage is. The more i think
>about it the worse it seems...
Most definately our disadvantage is IO.
You see, depth is very valuable. The biggest improvement thay they did
to Deep Blue was depth.
We have more processing power than Deep Blue, but that's only half of
what Deep Blue had: The other half is it's internal bandwidth. It must
be incredible! We are not. Our bandwidth is limited by the main server
on the front and 28.8 modems on the end.
Now, thinking only about bandwisth, not implementation:
Have a sever (proxy network) with the current status of the game. All
incoming clients can hit it for status.
Second, have a server (proxy network) that receives results. The main
receiving server will then simply take the highest valued move.
There is a time limit on the moves. But this is a total time, not a per
turn time (right?). How do we decide how long to "think" for any
Lets say that we are going to think for exactly one minute: If you
dispense the board at the start of the minute and then each client has to
repoert at the end of the minute. Obviosly, this won't work. IO!
We need to find a way to distribute the work such that the speed of each
client is proportianally used. Further, what happens if a client has a
network hiccup? Can't report for a while.
I think that we need to start "thinking" about all possible moves. Then
reporting them. As the game progresses, entire chunchs of the search
space that has already been searched will be discarded because the game
didn't progress that way. But by the same token, a small portion will
have been searched already--THIS IS WHERE WE CAN GET AHEAD OF DEEP BLUE!
As soon as a move is completed, we have a head start on the search.
Now, each client will have to KNOW what portion of the search space to
work on. If we try to put too much intelligence into the servers we will
Maybe we could give each client a number when they check into the proxy.
This number will allow a computer to hash which portion of the search to
do. The danger is that a slow client will of course not do as much as a
faster client. We can't benchmark each client because it's relative--if
we bench it when that machine is not busy then start working and the
machine gets busy doint "real" work...
Anyway, use our power to search many possibilities ahead of time.
ryan at jtmd.com
James Tower Media Design
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.
More information about the rc5