2 ms·

I mean, the most interesting part of the article for me: > A bit surprisingly the AVX2 parser on 9950X hit ~20GB/s! That is, it was better than the AVX-512 bas

I mean, the most interesting part of the article for me: > A bit surprisingly the AVX2 parser on 9950X hit ~20GB/s! That is, it was better than the AVX-512 based parser by ~10%, which is pretty significant for Sep. They fixed it, that's the whole point, but I think there's evidence that AVX-512 doesn't actually benefit consumers that much. I would be willing to settle for a laptop that can only parse 20GB/s and not 21GB/s of CSV. I think vector assembly nerds care about support much more than users.

vardump 1y ago
That probably just means it's a memory bandwidth bound problem. It's going to be a different story for tasks that require more computation.
- wyager 1y ago
  You can still saturate an ultrawide vector unit with narrower instructions if you have wide enough dispatch
neonsunset 1y ago
AVX512 is not just about width. It ships with a lot of very useful instructions available for narrower vectors with AVX512VL. It also improves throughput per instruction. You're not hand-writing intrinsified code usually yet compilers, especially JIT ones, can make use of it for all sorts of common operations that become x times faster. In .NET, having AVX512 will speed up linear search, memory copying, string comparison which are straightforward, but it will also affect its Regex performance which uses SearchValues<T> which under the hood is able to perform complex shuffles and vector lookups on larger vectors with much better throughput. AVX512 lends itself to a more compact codegen (although .NET is not perfect in that regard, I think it sometimes regresses vs AVX2 with its instruction choices, but it's a matter of iterative improvement).