Post by kristjanbb02 on Mar 6, 2009 18:48:39 GMT -5
Finished getting kif2pl converter working and did some fixes so now I can use SWI and GNU as well as YAP as back-end. I found the results interesting and very happy to see the improvement over our first prototype (see above) ;D
YAP - byte-code (+/- 1%): 670.5 plays/sec and 87.8 games/sec (20117 plays and 2633 games in 30.0 seconds)
SWI - byte-code (+/- 2%): 321.2 plays/sec and 42.0 games/sec ( 9641 plays and 1261 games in 30.0 seconds)
GNU - byte-code (+/- 1%): 760.2 plays/sec and 99.7 games/sec (22811 plays and 2993 games in 30.0 seconds)
GNU - native-code (+/- 1%): 756.4 plays/sec and 99.3 games/sec (22694 plays and 2980 games in 30.0 seconds)
GNU-Prolog: There is no visible difference between byte-code and native compiled except for the start-up time. A benefit lost by the compilation duration anyway. I have not fully looked all the optimization options and they say it's supposed to be fastest.
From the manual:
meta-call and dynamically asserted clauses
So I might be doing something wrong and I still need to verify that YAP is running without bottlenecks.
Post by kristjanbb02 on Mar 11, 2009 9:09:20 GMT -5
Final update. Using some few more enhancements such as:
Psyco a specializing just-in-time compiler for Python
Lots of caching (move generation, terminal, etc) and restore / store avoidance
A finally smart tree building.
Expand rate is pushed to 4500 p/s (single core), (1900 p/s raw from Prolog without caching).
So TicTacToe is now solved completely and generically in 12.6 seconds just in the analyze-phase thanks to the smart 'tree' building (technically a graph that can then be searched completely really fast compared to using Prolog in the play phase).
The analyze phase is random simulation based, but builds the graph depth first and ensures complete graph if memory allows (doing cut-off and such to prevent redundant work).
The hope is that evaluation functions can be constructed using data from this deep tree to help guide the UCT (if needed).