On Sat, Dec 17, 2022 at 12:08:08AM +0100, Paolo Bonzini wrote: > Because that's what configure used to do ( > https://lists.nongnu.org/archive/html/qemu-devel/2022-02/msg00650.html)... > > It can surely be changed but AVX512 is known to limit processor frequency. > I am not sure if the limitation is per core or extends to multiple cores, > and it would be a pity if guests were slowed down even further during > migration. > > Especially after the bulk phase buffer_is_zero performance matters a lot > less so you'd pay the price of AVX512 for little gain. After the bulk phase > it may even make sense to just use SSE, since even AVX requires a voltage > transition[1] from what I saw at > https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html.
Note: s/AVX512/Intel's AVX512 impl/ AMD's Zen4 AVX512 is said to behave quite differently from Intel's. This posting goes into a massive amount of detail: https://www.mersenneforum.org/showthread.php?p=614191 [quote] Since 512-bit instructions are reusing the same 256-bit hardware, 512-bit does not come with additional thermal issues. There is no artificial throttling like on Intel chips. [/quote] [quote] Overall, AMD's AVX512 implementation beat my expectations. I was expecting something similar to Zen1's "double-pumping" of AVX with half the register file and cross-lane instructions being super slow. But this is not the case on Zen4. The lack of power or thermal issues combined with stellar shuffle support makes it completely worthwhile to use from a developer standpoint. If your code can vectorize without excessive wasted computation, then go all the way to 512-bit. AMD not only made this worthwhile, but *incentivizes* it with the power savings. And if in the future AMD decides to widen things up, you may get a 2x speedup for free. [/quote] With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
