Hello !
End of March, Petr Baudis released his "Minimalist Pachi" called michi
(thread Michi - "15x15 ~6k KGS in 540 lines of Python code"). I found
the goals of his project (see the README at
https://github.com/pasky/michi) very attractive.
So, I decided to recode michi in C following Petr's suggestion
"One of the things I would hope to inspire is rewrite of the same
algorithm in different, faster programming languages".
I tried to keep C code very simple and translated michi python in a
straightforward manner when this was possible (almost everywhere).
The result is available at https://github.com/db3108/michi-c. (after
some discussion by email with Petr, we decided that it would be better
to make separate projects on GitHub)
Obviously the code got fatter (1300 executable lines of C instead of 540
of python). But it also got faster, almost a 10x acceleration, even if
it is yet single threaded.
Here is an extract of the results obtained against gnugo. More results
can be found in the perfs.txt attached file.
michi vs gnugo-3.7.10 level 10 (400 games 13x13)
------------------------------------------------
nsimulations/move 1400 4000 12000
python winrate (%) 36.5
code time per game (sec) 430.6
C winrate (%) 37.8 66.5 80.8
code time per game (sec) 44.2 123.4 340.7
michi vs gnugo-3.8 level 10 (400 games 13x13)
---------------------------------------------
nsimulations/move 1400 4000 12000
python winrate (%) 41.8
code time per game (sec) 419.5
C winrate (%) 38.8 66.5
code time per game (sec) 44.9 124.6
Uncertainty on winrates is between 2 and 2.4 %.
There is still a lot of room for improvements. As the speed of the
program is concerned, the 2 main ones are :
- parallelization
- fast board implementation with incremental update of blocks and liberties,
I have plans to continue to work on it with the priority of implementing
the fast board. Adapting existing and well tested code that I already
have, this should not take too long, I hope.
Meanwhile, if someone would like to try his hands on parallelization,
his efforts would be much apreciated. Some kind of coordination should
certainly be necessary, as I used for simplicity some constructs that
could prevent easy parallelization. But I hope this could be manageable.
For the above modifications we must relax the objective of brevity. So
this will be the right time to include some functionalities that will
increase the usability of the program (time management, variable
parameters modifiable by gtp commands for CLOP tuning, variable
boardsize, "intelligent" early passing, etc.)
I believe that these new developments should not be detrimental to the
clarity and the brevity of the original michi and I would like to let
michi-c unchanged (except for bug corrections and/or modifications to
make it clearer and shorter).
Therefore, I have setup another project for the new developments at
https://github.com/db3108/michi-c2
Any thoughts ?
PS. If someone can understand and help to correct the spurious message
got from gogui-regress when running make test, I would be very grateful. ;-)
Denis
Results below are obtained on two rather old quadcores i7-860 and i7-920
from 2010-2011.
------------------------------------------------
michi vs gnugo-3.7.10 level 10 (400 games 13x13)
------------------------------------------------
uncertainty about 2.4 % on winrates
nsimulations 1400 4000 12000
python winrate (%) 36.5
code time per game (sec) 430.6
C winrate (%) 37.8 66.5 80.8
code time per game (sec) 44.2 123.4 340.7
---------------------------------------------
michi vs gnugo-3.8 level 10 (400 games 13x13)
---------------------------------------------
nsimulations 1400 4000 12000
python winrate (%) 41.8
code time per game (sec) 419.5
C winrate (%) 38.8 66.5 ??
code time per game (sec) 44.9 124.6
-----------------------------------------------------------------------
michi vs gnugo-3.7.10 level 10 (400 games 13x13, without large pattern)
-----------------------------------------------------------------------
With visit_to_expand = 8
nsimulations 1400 4000 12000
C winrate (%) 20.0 50.5
code time per game (sec) 44.6 125.1
-----------------------------------------------------------------------
michi vs gnugo-3.7.10 level 10 (400 games 13x13, without large pattern)
-----------------------------------------------------------------------
With visit_to_expand = 2
nsimulations 1400 4000 12000
C winrate (%) 21.5 52.8
code time per game (sec) 47.8 134.6
--------------------------------------------------------------------
michi vs gnugo-3.8 level 10 (400 games 13x13, without large pattern)
--------------------------------------------------------------------
With visit_to_expand = 8
nsimulations 1400 4000 12000
C winrate (%) 73.5
code time per game (sec) 351.3
------------------------------------------------
michi vs gnugo-3.7.10 level 10 (400 games 15x15)
------------------------------------------------
nsimulations 1400 4000 12000
C winrate (%) 11.0 50.0
code time per game (sec) 98.9 299.2
------------------------------------------------
michi vs gnugo-3.7.10 level 10 (400 games 19x19)
------------------------------------------------
nsimulations 1400 4000 12000
C winrate (%) 4.8 ongoing
code time per game (sec) 326
_______________________________________________
Computer-go mailing list
[email protected]
http://computer-go.org/mailman/listinfo/computer-go
