Performance trap solver.reset()

[ColaColin]

I needed to generate a dataset of connect 4 positions from python. The quickest way to do so seemed to be to just call the main.cpp with subprocess. That worked alright, but was slow.

Long story short: solver.reset() triggers the transposition table to be reset. That means writing 80mb of zeros to memory. Even when you try to multi thread and run multiple solvers in parallel you won't see any speed ups, as the program is memory bandwidth bound, that had me quite confused for a few hours.

It might be prudent to remove the transposition table reset from the main, it might save somebody else some time debugging performance issues :)

Apart from this nasty trap: Great work on this solver, it really helps my current project a lot.

[PascalPons]

Thanks Colin for your feedback, I'll remove the reset line.

You are absolutely right that there is no need to reset the transposition table between each position resolution. The reset was there as my last version was used to generate an opening book (available here https://github.com/PascalPons/connect4/releases/tag/book).
To generate such book I solved all <12 depth position and kept the most complex positions, complexity being measured by the number of explored node. Without reseting the transposition table, the number of explored nodes (and processing time) was highly biased by the previous state of the transposition table.

Second point, be careful that the transposition table is not thread-safe. So make sure to have one instance of solver and transposition table per thread. for a batch resolution, it could be more convenient to run multiple process rather than multi-thread.

[ColaColin]

I actually call your solver from python via cython, so I have no choice but to make multiple processes :)

[selectany]

Thanks Colin for your feedback, I'll remove the reset line.

You are absolutely right that there is no need to reset the transposition table between each position resolution. The reset was there as my last version was used to generate an opening book (available here https://github.com/PascalPons/connect4/releases/tag/book). To generate such book I solved all <12 depth position and kept the most complex positions, complexity being measured by the number of explored node. Without reseting the transposition table, the number of explored nodes (and processing time) was highly biased by the previous state of the transposition table.

Second point, be careful that the transposition table is not thread-safe. So make sure to have one instance of solver and transposition table per thread. for a batch resolution, it could be more convenient to run multiple process rather than multi-thread.

About generating an opening book, you don't have to reset TT if all your positions set (file) you load, are with a same length.