5 ms·

"...even better is long term competition in this space." I hope that's the biggest outcome from this. My inside sources tell me that Intel has their briefs in

"...even better is long term competition in this space." I hope that's the biggest outcome from this. My inside sources tell me that Intel has their briefs in a bind over AMDs latest technology, and are certainly kerfuffling over it, but I'm not sure how quickly they can respond. It seems like the disparity in this cycle has grown wider than in the past. But that is just my subjective take - I'm not really conversant on the manufacturing part. I'm just historically reviewing the power consumption and benchmarks.

close04 7y ago
> but I'm not sure how quickly they can respond AMD won't be in the position to just rest on their laurels for years to come. So the fact that Intel is scrambling to come up with a competitive response shouldn't be a concern as far as competition goes in the short-medium term. I'd say we have at least a few CPU generations coming from AMD without worrying that they become complacent, even if Intel still comes up short.
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 ago
  There’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 ago
    They 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 ago
      Ryzen 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 ago
      The rest of you folks make me feel dumb - but nice posts, I'm doing a lot of Googling now...
- trimbo 7y ago
  I 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 ago
    From 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.

close04 7y ago

> but I'm not sure how quickly they can respond AMD won't be in the position to just rest on their laurels for years to come. So the fact that Intel is scrambling to come up with a competitive response shouldn't be a concern as far as competition goes in the short-medium term. I'd say we have at least a few CPU generations coming from AMD without worrying that they become complacent, even if Intel still comes up short.

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 ago
There’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 ago
  They 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 ago
    Ryzen 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 ago
    The rest of you folks make me feel dumb - but nice posts, I'm doing a lot of Googling now...
trimbo 7y ago
I 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 ago
  From 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.