Comparison experiment: reuse the Rayon pool instead of own threads (not for merge) #18

Comparison experiment for the maintainer, not for merge. main keeps the own-threads version (#16), and 0.2.0 is not published.

Question

Can faer#107 be solved while staying on Rayon? The test uses the same acceptance criteria (a)-(d) as #14 and #16.

Hypothesis

• Waits like the OpenMP runtimes: bounded poll spin, yields, then sleep; wait benchmarks (faer#107) #14 failed (a) because every per-call pool started fresh threads, not because of how it waited.
• 0.1.3 already met (b) and (c).
• So reusing the Rayon pool between pools should be enough.

Experiment

Branch exp/rayon-pool-reuse, from 625a593: Rayon underneath, with libgomp's waits only, no detection and no warm-up.

• A Pool with default thread settings (no thread_name, on_start, stack_size or qos) returns its private rayon::ThreadPool to a process-wide, per-width cache on drop.
• The next Pool::build of the same width takes it from the cache.
• Only idle entries are lent, so two live pools never share a Rayon pool.
• On reuse, each worker re-applies the caller's CPU mask.
• The cache cap follows Own worker threads: a process-wide reserve of std::thread workers instead of a private Rayon pool (#15) #16: the larger of the available parallelism and the widest pool built so far.
• These invariants are kept:
  • no implicit global pool;
  • alloc_free;
  • loom;
  • no public Rayon;
  • self-drop.

Measurement

broccoli and evo run three sides: base a3a9320, this branch, and 302c37d (main, 0.2.0). The faer probe runs every arm of (a). The monitor sends the measurement requests.

Refs #14, #15, #16, tensor4all/faer#107.