h48

A prototype for an optimal Rubik's cube solver, work in progress.
git clone https://git.tronto.net/h48
Download | Log | Files | Refs | README | LICENSE

commit bb09e52a7481718ae1fe324d16b99970450908f8
parent 89e0bc567960199dec774e5449e471dd31ef440b
Author: Sebastiano Tronto <sebastiano@tronto.net>
Date:   Fri, 20 Sep 2024 11:42:13 +0200

Added comment on performance issue

Diffstat:
Msrc/solvers/h48/gendata_h48.h | 13+++++++++++++
1 file changed, 13 insertions(+), 0 deletions(-)

diff --git a/src/solvers/h48/gendata_h48.h b/src/solvers/h48/gendata_h48.h @@ -284,6 +284,19 @@ gendata_h48h0k4_return_size: return H48_TABLESIZE(0, 4) + INFOSIZE; } +/* +TODO: the following function suffers from a big performance loss (about 40%) +because of all the mutex locking. It is possible to reduce the first lock +(at the beginning of the outermost for loop) by caching the next few items at +once and then looping over the cached elements. But for the second one (inner +loop) the access is non-sequential, so this cannot be done. + +However, in both cases in theory we do not care if we are reading the old +value or the updated one. Depending on the compiler guarantees on concurrent +memory access, we may be fine just removing the locks altogether. + +It is probably possible to solve part of this by using atomics. +*/ STATIC void * gendata_h48h0k4_runthread(void *arg) {