|
Post by kristjanbb02 on Feb 9, 2009 18:10:48 GMT -5
I just finished my first implementation of min-max and counting the store-next-restore's over few game runs I get 130 about expands per second using YAP on running on 2Ghz using single core. Seems rather low? I was hoping to be closer to 500 What I would really curious to see what expand rate people are getting for reference.
|
|
|
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: Type | Speed | Debug ? | For what | interpreted-code | slow | yes | meta-call and dynamically asserted clauses | byte-code | medium | yes | consulted predicates | native-code | fast | no | compiled predicates |
So I might be doing something wrong and I still need to verify that YAP is running without bottlenecks.
|
|
|
Post by kristjanbb02 on Mar 6, 2009 22:31:54 GMT -5
Take two with small improvements that I highly recommend if you use high latency interface: - Getting the state as list
- Fetching the moves as list
- Restoring the state as list
GNU (~83% increase): 1388.0 p/s and 182.3 g/s or 325259 plays and 42709 games in 234.3 seconds YAP (~59% increase): 1066.3 p/s and 139.9 g/s or 282032 plays and 37011 games in 264.5 seconds SWI ... didn't really work as it dots the end of the list and I haven't figured out how to turn that feature off. If anybody knows please post. Example: ?- state_get_moves_as_list(xplayer,L). L = [mark(1, 1), mark(1, 2), mark(1, 3), mark(2, 1), mark(2, 2), mark(2, 3), mark(3, 1), mark(3, 2), mark(..., ...)]. p.s. Useless fact: in the SWI v5.6.62 code there are 4931 occurences of '...'
|
|
|
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).
|
|