Re: computer-go: Languages for programming go are?

[Don Dailey <drd@xxxxxxxxxxxxxxxxxxxxx>]

I don't think there  can be a good benchmark   of pure speed.  No  two
programs do the same  thing.  But when I  read your description  I was
surprised at how  similar your data  structure  seemed to be to  mine.
But maybe it's not that similar, you do more things  that I do.  But I
think seeing  your  numbers  was  useful  to  me anyway,  because   it
motivated me to  think  about what was  going  on.

Don



   From: "Phil" <PhilippGarcia@xxxxxxxxxxxxxxxxx>

   Thanks Don & Anders!

   After reviewing my random game test algorithm, I must state that is
   shouldn't be used as a benchmark (my mistake). It's main purpose was to find
   bugs. It works by generating completely random moves and attempting to play
   them. An illegal move is turned into pass (12% of all moves). This,
   unfortunately, inflates the performance figures. So that we can compare
   apples to apples, can anyone propose a benchmark algorithm?

   Phil

   ----- Original Message -----
   From: "Don Dailey" <drd@xxxxxxxxxxxxxxxxx>
   To: <computer-go@xxxxxxxxxxxxxxxxx>
   Sent: Tuesday, January 02, 2001 9:37 AM
   Subject: Re: computer-go: Languages for programming go are?


   >
   >    From: "Anders Kierulf" <anders@xxxxxxxxxxxxxxxxx>
   >
   >    > Anyway, I'm curious about what other knowledge is incrementally
   updated
   >    > by my fellow Go programmers, and how, if you don't mind.
   >
   >    SmartGo currently keeps the following information up-to-date:
   >    - Number of black and white stones on the board.
   >    - Zobrist hash code (64 bits).
   >    - Number of empty neighbors for each point.
   >    - The stones in each block (in a circular linked list).
   >    - The anchor (smallest stone in a block) of each stone.
   >    - The liberties and liberty count of each block (in an array).
   >    - (Optional) Bitboards for all black, white, and empty points.
   >
   >    > Just for some sporty fun, my Go program on PIII-500 can execute about
   >    > one million random moves in under 5 seconds:
   >    >
   >    > Board::TimingTests()
   >    > ---> Playing Random Game
   >    > ***> 1000000 Turns
   >    > ***> 4.625 seconds.
   >    > ***> 216216 turns per second.
   >
   >    Can you elaborate on what you mean by playing random games? To make it
   a
   >    more realistic test, it should probably include taking back the moves
   >    played, and also check some random liberty counts and iterate through
   >    liberties between moves.
   >
   >    Anders Kierulf
   >    www.smartgo.com
   >
   >
   > Are these numbers based on taking back moves or just making them?
   >
   > I would like to emphasize that my test  does both.  Even though taking
   > back moves is free for me,  I presumably pay for this  up front with a
   > slower move maker.   (Actually, is my move  maker really slower?   I'm
   > not convinced of   this  because every   program  has to  provide   an
   > equivalent mechanism  and extra logic for taking  back moves.)
   >
   > I get 300,000 nodes per second, on a pentium II  laptop running at 400
   > MGH which includes evaluation,  which is  fast  and simple, but  by no
   > means free.
   >
   > Phil's program  is  doing some  work mine does  not do,  because he is
   > keeping some  bit boards  updated too.   So it's  hard to construct an
   > apples to apples test unless he can  turn that stuff  off.  I have yet
   > to see a good   reason to turn   my program into  a hackery  of global
   > variables that are updated  in place, but I would  do this if it meant
   > extra speed.  I don't know of a fair way to test this without actually
   > going through this excercise, but I  need a lot of motivation, because
   > I think my program is at least pretty fast, if nothing else.
   >
   >
   > Don
   >