[rc5] v3

Ryan Krueger 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 
particular turn?

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 
kill ourselves.

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 Krueger
Senior Analyst
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 mailing list