3 ms·
Especially as the top dual socket Epyc BEATS the top dual socket Xeon in a workload heavily optimised for AVX-512 and using the Intel ICC compiler. True, it ha
by philjohn 7y ago
Especially as the top dual socket Epyc BEATS the top dual socket Xeon in a workload heavily optimised for AVX-512 and using the Intel ICC compiler.
True, it has more cores, but it seems Xeon's have to clock down when executing AVX-512 ops to stay within their power budget.
It's also doing this at almost half the cost and consuming less power ... that's nothing short of astounding.
Xeon's do have a benefit for workloads that can stay in L3 cache as their mesh means latency is stable, whereas Epyc is 16MB per CCX.
Overall memory latency is also lower, which is the tradeoff with the IO die, but it will be interesting to see what real world numbers for DB's etc. say about that.
- stochastic_monk 7y agoThere’s a hit that comes from “frequency scaling” on avx512 and avx2 instructions on Intel (worse for 512), so a total of fewer instructions isn’t always worth it. IIRC, AMD doesn’t pay a cost for avx2, but I don’t know how it works.
- Tuna-Fish 7y agoThey pay a cost for it in sense of having to clock lower if they run a lot of AVX code, but they advertise their AVX2 clock as their base clock, and more importantly, they can change clock at a much finer granularity and only have to change after a latency period. The problem with the AVX2/AVX512 clocks with Intel is not the fact that they must clock lower to use them (for pure AVX code, running wider but at the lower clock speed is still worth it!), it's that they need to clock lower pre-emptively for any such instructions, and must remain at this lower clock for a while. This means that code that executes a few AVX instructions every now and then mixed in with a lot of integer code needs to run the whole program at a lower clocks. In contrast, AMD runs their chip power supply from a huge mimcap built in the chip, meaning that they have margin so they can start executing exceptionally power-hungry instructions, and only clock down reactively if it's actually needed. And also do the clocking down and up with a much finer granularity, clocking up immediately after the need to clock down passes.
- ahartmetz 7y agoRyzen also uses clock stretching where single(?) clock cycles can be lengthened on demand (power transients), which allows running stable at otherwise marginal clock speeds. I suspect that that is part of the reason why Ryzens have so little overclocking headroom - there are tiny safety margins in their clock frequency.
- redleggedfrog 7y agoThe rest of you folks make me feel dumb - but nice posts, I'm doing a lot of Googling now...
- trimbo 7y agoI don't have exact performance numbers handy and haven't measured it personally but... from what I understand: * With heavy avx instructions churning, AVX should still be a net positive performance-wise even when clocking down. * It's when you're running AVX mixed with non-vector code that you can see the performance effects of clocking down, since you can drop way down from Turbo on non-vector instructions. Here are the different ranges [1] [1] - Pages 14-21 https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-scalable-spec-update.pdf https://www.intel.com/content/dam/www/public/us/en/documents...
- robert_foss 7y agoFrom the Anandtech benchmark it was made clear that there is more than AVX-512 vs. clockspeed going on. Apparently AMD deemed implementing AVX-512 to be less desirable than spending the same silicon area on more cores. So there's both AVX-512 vs. clockspeed & AVX-512 vs. silicon budget going on. For many usecases having extra cores is a good trade-off.