Hello, I'm trying to write my own go playing program. Right now it is GnuGo style program - no dedicated search is performed. It is pleasure to see bot improving, but recently I decided to learn and implement MCTS, meaning I have to use my go board implementation often (for playouts). I see some fundamental performance problems, but can't decide if it is lack of my programming knowledge or need of paradigm shift. I'm having around 1000 playouts/s with very light playouts (which, as I understand, is very small number). My playouts consist of selecting all empty fields, which are not potential eyes of player to move and playing one at random. Benchmarking shows, that current biggest offender is function, which checks if field is potential eye, by checking values of color array around point of interest. My board implementation is strightforward - one dimensional array of colors of intersections (black, white, empty or border) and some additional info like player to move, ko position, etc. Not going into programming part I would like to ask, if there would be benefit of also having other arrays for liberties, numbers of neighbours and so on, which I would update incrementally and then check? Looks like such libraries like Fuego or libego use this approach. Or I am looking at this problem from wrong side and need to search for bottlenecks in code itself? Thank you in advance.
_______________________________________________ Computer-go mailing list Computer-go@computer-go.org http://computer-go.org/mailman/listinfo/computer-go
