https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127893
--- Comment #21 from [email protected] --- Results from x86_64 Ubuntu-provided gfortran-16 patched with Jerry's patch, on Threadripper PRO 3975WX 32-Core running Ubuntu 26.04.1 LTS. Somewhat late I provide the results of the full reproducer benchmark, attachment 65844 from bug 127893 (5,000,000 unformatted reads, each thread its own file + unit), 3 reps each, medians shown. Program's own omp_get_wtime elapsed : threads gf13. gf14. gf15. gf16. gf16-patched 1 0.636 0.537 0.630 0.613 0.520 4 1.403 1.338 1.393 1.355 0.261 8 2.276 1.956 2.266 2.278 0.179 16 2.333 2.114 2.155 2.374 0.128 32 1.772 1.672 1.775 1.636 0.080 What this shows: On Linux there is essentially no gcc-13→14 rwlock regression in this reproducer — gf13 is just as lock-bound as gf15/16 (all spend 1.3–2.9 s in sys!). Pre-rwlock gf13's per-unit mutex costs the same here. The macOS-style 4× version regression (Darwin's __psynch_rw_*) does not reproduce on glibc. But the lock/lookup overhead itself is huge and compiler-independent — and Delisle's committed fix (direct-mapped unit cache + free-list, verified present: recycle_unit/probe_unit_cache/unit_free_list) kills it completely: 5× faster at 4 threads, up to ~21× at 32, with sys time collapsing from ~2–3 s to ~0.003 s. Even at 1 thread the patch is ~15% faster.
