John on big/little architectures

I ran some benchmarks on Intel 13900 and I have a feeling that the way john spreads work among threads is not optimal on machines with two types of cores. It seems like it is assuming that it will take similar amount of time for each set of hashes to be computed, which is not true if we have two way different types of cores. I suspect that P cores are done and they are waiting in synchronization point for E cores. The difference in performance is 2x, so they wait for half of the time.

I am not sure if this is john, or OpenMP's fault to be honest, without more digging, but I wanted to leave a note before I forget about that.

All cores:
OMP_NUM_THREADS=32 ./john -test -format=raw-sha256
Will run 32 OpenMP threads
Benchmarking: Raw-SHA256 [SHA256 256/256 AVX2 8x]... (32xOMP) DONE
Raw: 108770K c/s real, 3432K c/s virtual

P cores only - no HT (116K with HT)
OMP_PLACES='{0},{2},{4},{6},{8},{10},{12},{14}' OMP_NUM_THREADS=8 ./john -test -format=raw-sha256
Will run 8 OpenMP threads
Benchmarking: Raw-SHA256 [SHA256 256/256 AVX2 8x]... (8xOMP) DONE
Raw: 118947K c/s real, 14868K c/s virtual

E cores only:
OMP_PLACES='{16},{17},{18},{19},{20},{21},{22},{23},{24},{25},{26},{27},{28},{29},{30},{31}' OMP_NUM_THREADS=16 ./john -test -format=raw-sha256
Will run 16 OpenMP threads
Benchmarking: Raw-SHA256 [SHA256 256/256 AVX2 8x]... (16xOMP) DONE
Raw: 80871K c/s real, 5045K c/s virtual

Start by reproducing the reported raw-sha256 benchmarks with the three OMP_NUM_THREADS and OMP_PLACES configurations on a big/little Intel system. Compare thread completion and synchronization behavior to determine whether the imbalance is in John or OpenMP. Done means the cause is established and a concrete, tested scheduling improvement is identified.