3 ms·
That's surprising, I would expect that codecs are doing enough work that the faster processing from AVX-512 more than pays for the downclocking. In JPEG XL we s
by janwas 3y ago
That's surprising, I would expect that codecs are doing enough work that the faster processing from AVX-512 more than pays for the downclocking.
In JPEG XL we saw 1.4x end to end speedup (including this downclocking) and that was for images, which are often less data than videos.
A policy of AVX-512-off-by-default seems pessimistic now that Intel Icelake+ have basically no throttling, and AMD Zen4 definitely none.
- touisteur 3y agoThe thing is now your codec (or libc as it was once!) is having a complex side effect. The clamping and ramping back up of the frequency is not immediate and it has an impact of overall latency on the core it's running. I even saw once funny traces on a heavily loaded machine where the avx512 code was rescheduled on other cores almost all the time, because overall the core running the avx512 code seemed to 'be more loaded' and the scheduler would find a new home for the avx512-crunching process. Kind of a 'fun' runaway process.
- janwas 3y agoFair point :) I wonder why the kernel is so aggressive about migrating threads, it also loses the cache contents. FWIW our command line tools at one point pinned themselves to the current core, which did help performance.
- gpderetta 3y agoOS kernels should be relatively sticky. Possibly it was power/temperature management where the load was moved to an unloaded core to even out power dissipation?