On 2016-04-22 09:43, Jonathan Ho wrote:
> It seems that all of the UCT code assumes that this board stays in
> memory during the entire duration of existence of the uct engine
> (from engine_uct_init until uct_done), because the tree is stored
> inside the uct data structure.
At the very least, "struct tree_node" is very sensitive to cache misses.
Removing 10% worth of only padding yielded about 10% improvement in
evaluations/s.
There are probably logic errors if "struct board" isn't kept consistent,
pasky or someone else can elaborate on the logic. I can't.
> I'm interested in writing Python wrappers for the various primitives
> in Pachi, such as boards and engines. In particular, I'm trying to
> make the UCT code accessible as a library, so that a user can give
> the UCT enginea board and ask it for a move.
> What is the meaning of this particular board? Is it safe to modify
> the tree structure so that it instead keeps a copy of a board instead
> of a pointer to it (i.e. modify tree_init to copy the board
> argument)?
I don't see a reason why to do that in the first place, taking account
Python's FFI approaches. At least please use cffi or other modern
library, not direct cpython integration.
> If not, does this mean that with a uct engine, I must keep track of
> an associated board that it operates on, and ensure that it is never
> deallocated over the course of the engine's lifetime?
Pachi takes care of the lifetime. See the call graph, read the functions
and you'll note it's not harder than for other C libraries.
If you need to marshal C <-> Python at all in the evaluation function,
it's a big performance hit. Try to avoid that.
sh