On Thu, Jul 23, 2026 at 11:44:05AM +0100, Matthew Malcomson wrote:
> > And, does it have to be allocated at all even if nthreads
> > is really small (say <= 16 or so)?
> > Has performance been compared even in the low number of threads
> > cases (i.e. shouldn't we dynamically choose between the hyper strategy
> > and the linear one)? Not everybody even now has lots of CPUs and
> > OpenMP is used even in the low number of threads cases, 2, 4, 8, 16...
>
> W.r.t. smaller thread counts: I did test performance of the barrier
> approaches on smaller thread counts. On most of the hardware I tested I
> found this approach still faster, just not by as much.
I haven't actually applied and benchmarked the patch myself, which is why
I was asking. I primarily care whether the patch is not an optimization
solely for large number of threads that at the same time slows significantly
the low number of threads case. If it is a wash, or sometimes small
improvement sometimes small regression for those cases, it is ok.
That said, if one can still configure the previous behavior (through
compiling on older kernel or --disable-linux-futex-waitv or similar), users
can choose that if it is beneficial for their workloads and they never need
more threads.
Jakub
