I played around a bit lately with finding ways to dramatically multithread code in golang, mostly for fun. What I found was that there was a threshold where the overhead of spinning up all the threads at the start and synchroninzing them at the end overwhelmed the time savings from actually performing the work in multiple threads.
It wouldn't surprise me if PDF renderer and background blur were fast enough tasks that spinning up 96 threads to split rendering across all those cores was a waste of time compared to how fast the actual task was to complete. It was akin to trying to hammer in 50 nails by getting 50 people and handing out 50 hammers and assigning each person one nail, then telling them "okay, start!", then inspecting everyone's work afterwards; at some point, it's faster just to break it into two or three tasks.
Comments
In addition to the single-core-clock-speed difference, the different tasks in the multicore benchmark seem to all have different performance characteristics: https://browser.geekbench.com/v6/cpu/compare/8423876?baselin...
For some reason the Epyc is radically faster for "Ray Tracer" and "Horizon Detection" but worse for "PDF Renderer" and "Background Blur"
I played around a bit lately with finding ways to dramatically multithread code in golang, mostly for fun. What I found was that there was a threshold where the overhead of spinning up all the threads at the start and synchroninzing them at the end overwhelmed the time savings from actually performing the work in multiple threads.
It wouldn't surprise me if PDF renderer and background blur were fast enough tasks that spinning up 96 threads to split rendering across all those cores was a waste of time compared to how fast the actual task was to complete. It was akin to trying to hammer in 50 nails by getting 50 people and handing out 50 hammers and assigning each person one nail, then telling them "okay, start!", then inspecting everyone's work afterwards; at some point, it's faster just to break it into two or three tasks.