Move from std:::thread to Windows Thread Pool #32

Activity

1. mgradwohl

   added

   enhancementNew feature or requestNew feature or request

   impact: performanceReview impact category: performanceReview impact category: performance

   priority: medFix next: reliability, maintainability, and high-value usabilityFix next: reliability, maintainability, and high-value usability

   review: 2026-11Repository-wide review at fdf20b4, November 2026Repository-wide review at fdf20b4, November 2026

   severity: lowLimited impact, maintenance improvement, or optional new capabilityLimited impact, maintenance improvement, or optional new capability

   on Nov 9, 2026
2. mgradwohl commented on Nov 9, 2026

   

   mgradwohl

   on Nov 9, 2026 – with Copilot SWE Agent

   OwnerAuthor

   More actions

   Repository-wide review: 2026-11

   Classification: recommendation. Severity: low. Priority: med. Impact: performance.
   Reviewed revision: fdf20b4cbfbbb8009d45296f3d60f0f541ee539b.

   Evidence

   Board.cpp:330-349, Renderer.cpp:154-188, MainWindow.xaml.cpp:330-345.

   Finding

   Both simulation and rendering create/join 2..8 OS threads on every draw; the UI callback waits for both phases. Merely switching the spelling to std::jthread gives scoped joining, not persistent workers. The work uses multiple parallelism mechanisms and has no benchmark evidence for always parallelizing small boards.

   Recommended change

   After correctness fixes, benchmark serial work versus reusable bounded workers/Windows thread pool and choose measured thresholds. Consider publishing immutable generations from a background simulation worker rather than blocking the UI. Keep bounded work/cancellation/backpressure and propagate failures correctly. Treat sparse/HashLife or GPU engines as later experiments, not a shortcut around the current rule/ownership defects.

   Acceptance criteria

   • Benchmark 25x25, default 300x300, and 700x700 sparse/dense boards.
   • Record update/render/frame latency, thread creation, and UI responsiveness separately.
   • Results remain identical across worker counts and shutdown is bounded.
   • Avoid claiming speedups until measured on representative x64/ARM64 machines.

   Related context / sources

   Comparable architecture ideas: Golly has distinct QuickLife/HashLife algorithms (bundled algorithm docs mirror); Ready uses OpenCL for continuous/discrete automata (project README). Their semantics/workloads differ; GPU acceleration and HashLife are not universally faster.
3. mgradwohl commented on Nov 9, 2026

   

   mgradwohl

   on Nov 9, 2026 – with Copilot SWE Agent

   OwnerAuthor

   More actions

   Backlog triage

   Status: Still open.
   Severity: low. Priority: med. Impact: performance.
   Assessed against fdf20b4cbfbbb8009d45296f3d60f0f541ee539b.

   Evidence

   Board.cpp:330-349

   Disposition and remaining scope

   Still outstanding. Simulation and rendering still construct/join jthreads for every frame; no reusable worker pool exists.

   Completion criteria

   • Benchmark 25x25, default 300x300, and 700x700 sparse/dense boards.
   • Record update/render/frame latency, thread creation, and UI responsiveness separately.
   • Results remain identical across worker counts and shutdown is bounded.
   • Avoid claiming speedups until measured on representative x64/ARM64 machines.
4. mgradwohl

   removed

   review: 2026-11Repository-wide review at fdf20b4, November 2026Repository-wide review at fdf20b4, November 2026

   on Nov 9, 2026