Re: [computer-go] Bitmap Go revisited and mockup implementation

2009-08-26 Thread Antoine de Maricourt

René, please don't apologize.
I will start to feel embarassed...

I am very happy that you came out with a working implementation of the 
ideas I explained, as I never really did it (I only had made some 
preliminary implementation in order to evaluate the interest).
Arguments people give on this list (pros and cons) are often a way for 
them to persuade themself whether they should follow your direction or 
not, not a way to judge your work.


And I think you're right when saying many of us are stuck to 9x9.
It may not last very long (see Fuego), but even writing a top program 
for 9x9 is still a challenge especially on standard hardware (I mean a 
simple computer, not a cluster).


I have no definitive idea about the "pure speed" vs "intelligence" argument.
I think the optimum probably combines both of them.
Therefore, fast light playouts might very well have its place, and an 
efficient bitmap implementation can be interesting.


I'm pretty sure you can improve your code.
Removing branch and jumps, as well as limiting the memory throughput 
(these are usually the main bottlenecks), is probably the best way to do it.
I remember I managed to get up to 30 % in code speed on some of my 
programs just by doing this.


If you want to get more portable code, you might consider to install 
mingw (with msys) or cygwin on your Windows box.
Chances are that if you write code for VC++ and can get it compiled with 
g++, it will be much more portable.


Best regards,

   Antoine
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/


[computer-go] congrats to Fuego! from US Go email

2009-08-26 Thread terry mcintyre
FUEGO BEATS PRO IN 9X9 EVEN GAME: The
Fuego computer go program won a 9x9 even game against 9-dan
professional Chou Chun-Hsun (Zhou Junxun, left) at the Human vs.
Computer Program Competition (FUZZ-IEEE 2009) event held August 21-22
on Jeju Island, Korea. Fuego played three official games
with Zhou, winning the first - taking white -- by 2.5 points. This is
the first time that a computer program has won a 9x9 game on even
against a top-ranked player. "Everybody considers the win of Fuego in
9x9 as very good," said Olivier Teytaud, leader of the MoGo team. "No
error from the pro, just a perfect play by the computer." Click here for
the game record. The Fuego team includes Markus Enzenberger, Broderick
Arneson, Rich Segal (IBM) and Gerry Tesauro (IBM). The Japanese program
Zen also put in a very strong performance, beating amateur Chang
Shen-Su 6d with both Black and White on 9x9. The other two computer
participants, MoGo and Many Faces of Go, did not win any games; click here for
full results. "I would like to thank everyone who helped," says Martin
Mueller, "especially Steve Sutphen for getting Fuego set up on the
cluster, and Jonathan Schaeffer for financial support, and for allowing
us to use his machine with its 80 cores." - photo of Chou Chun-Hsun by Jimmy Lin
 Terry McIntyre 
"And one sad servitude alike denotes
The slave that labours and the slave that votes" -- Peter Pindar



  ___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Bitmap Go revisited and mockup implementation

2009-08-26 Thread Michael Williams

I only showed the first line.  There were many more.  Gotta go to work though.

René van de Veerdonk wrote:

Micheal,

Is that all the output you get? Did you notice that the first line with 
test-error changed ... the second number went from 31 to 32. We did 
something! But not what I expected. BTW. The program does not normally 
crash, it just stops after its initial testing is completed and errors 
were detected. If you actually went from a gazillion line to just one, 
we have hit a nerve. I you just didn't bother to copy the rest of the 
output, we made no progress. But, since the output actually changed, it 
would still be nice to see a few more lines and see the trend.


Thanks for helping ... debugging for someone else must not be the best 
use of your time,


René

On Tue, Aug 25, 2009 at 8:03 PM, Michael Williams 
mailto:michaelwilliam...@gmail.com>> wrote:


No.  The code is now:


__forceinline
unsigned int bitmap_t::lowest_index () const {
 const __m128i comp = _mm_cmpeq_epi32 (_mm_setzero_si128 (), board);
 unsigned long m = _mm_movemask_epi8 (comp) ^ 0x;
 if (!_BitScanForward (&m, m)) return 127;
 /* offending instruction */
 //return 8*m + __lzcnt (board.m128i_u32[m/4]);
 /* new code follows */
 unsigned long n;
 _BitScanForward (&n, board.m128i_u32[m/4]);
 return 8*m + (32-n);
}


Debug:
testing _BitScanForward (&m, 0): 0 1099227377

testing _BitScanForward (&m, 1): 1 0
testing _BitScanForward (&m, 256): 1 8
testing _BitScanReverse (&m, 0): 0 1103042705

testing _BitScanReverse (&m, 1): 1 0
testing _BitScanReverse (&m, 256): 1 8
test-error [bitmap_t::lowest_index]: 0 32

Release:

testing _BitScanForward (&m, 0): 0 16843009
testing _BitScanForward (&m, 1): 1 0
testing _BitScanForward (&m, 256): 1 8
testing _BitScanReverse (&m, 0): 0 4
testing _BitScanReverse (&m, 1): 1 0
testing _BitScanReverse (&m, 256): 1 8
test-error [bitmap_t::lowest_index]: 0 32



René van de Veerdonk wrote:

Micheal,

Your output is actually correct. The output is undefined when
the second argument to _BitScanForward is zero and that is what
I am explicitly testing for in the method
bitmap_t::lowest_index, which is supposed to return an index to
any set bit (despite the name). Your output shows that it
returns a number that is off in a very predictable way (it seems
that replacing "8*m + n" with "8*m + (32-n)" on the last line
may do the trick for you, but it breaks my local copy). So, now
I am positively baffled.

Help?

René

On Tue, Aug 25, 2009 at 7:25 PM, Michael Williams
mailto:michaelwilliam...@gmail.com>
>> wrote:

   Debug build:
   testing _BitScanForward (&m, 0): 0 842032512

   testing _BitScanForward (&m, 1): 1 0
   testing _BitScanForward (&m, 256): 1 8
   testing _BitScanReverse (&m, 0): 0 840277132

   testing _BitScanReverse (&m, 1): 1 0
   testing _BitScanReverse (&m, 256): 1 8

   Release build:

   testing _BitScanForward (&m, 0): 0 16843009
   testing _BitScanForward (&m, 1): 1 0
   testing _BitScanForward (&m, 256): 1 8
   testing _BitScanReverse (&m, 0): 0 4

   testing _BitScanReverse (&m, 1): 1 0
   testing _BitScanReverse (&m, 256): 1 8

   Sucks when they produce different results.



   René van de Veerdonk wrote:

   Micheal,

   Thanks for trying. Could you try one or two more things?

   (1) Replace the _BitScanForward in the new code to
   _BitScanReverse. This probably won't help.

   (2) Add this to bitmapgo.cpp:

   /* sandbox */
   const bool sandbox = true;
   void test_sandbox () {
unsigned long m = 220;
unsigned char test_it = _BitScanForward (&m, 0);
std::cout << "testing _BitScanForward (&m, 0): "
  << (int) test_it << " " << m << "\n";
test_it = _BitScanForward (&m, 1);
std::cout << "testing _BitScanForward (&m, 1): "
  << (int) test_it << " " << m << "\n";
test_it = _BitScanForward (&m, 256);
std::cout << "testing _BitScanForward (&m, 256): "
  << (int) test_it << " " << m << "\n";
test_it = _BitScanReverse (&m, 0);
std::cout << "testing _BitScanReverse (&m, 0): "
  << (int) test_it << " " << m << "\n";
test_it = _BitScanReverse (&m, 1);
std::cout << "testing _BitScanReverse (&m, 1): "
  << (int) test_it << " " << m << "\n";
test_it = _BitScanReverse (&m, 256);