[Computer-go] michi-c a recoding in C of Petr Baudis's michi
jason.james.house at gmail.com
Tue May 12 07:58:50 PDT 2015
Michi's source is more than 540 lines. I've wondered about trying to split
the source into 3 pieces:
- UI/glue code not in the line count
- Board implementation
- Core playout/search code
I imagine that would allow easier customization of the board
implementation... Both in python or in ports to other languages.
I also think the core payout and search code would be a good candidate for
automated conversion to another language, but I may be underestimating the
difficulty of that!
On May 12, 2015 9:55 AM, "Denis Blumstein" <denis.blumstein at orange.fr>
> 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
> 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
> 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. ;-)
> Computer-go mailing list
> Computer-go at computer-go.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Computer-go