3 ms·

If someone writes a program with AVX instructions and one without, saying the second is one third the speed is completely disingenuous. SIMD instructions aren'

If someone writes a program with AVX instructions and one without, saying the second is one third the speed is completely disingenuous. SIMD instructions aren't the difficult part of matching Intel's CPU architecture. Fast cache hierarchies, prefetching, branch prediction and out of order instructions etc. are the parts that have to be matched.

BeeOnRope 8y ago
Well of course SIMD performance is part of the "hard part", because it implies things like very wide cache access, including perhaps unaligned access, high bandwidth between cache levels, wide register files, etc. Plus a sane ISA extension strategy that actually gets people to use your SIMD instructions helps a lot (Intel hasn't done well here, but so far neither has ARM e.g., with almost non-existent support for SVE). SIMD performance is one place that Intel is still fairly far ahead of both AMD and the ARM competition (with Apple far out ahead in that group).
- BubRoss 8y ago
  I'm not sure what a sane ISA has to do here, the parent was comparing a SIMD accelerated program to a non-SIMD program and using that to compare two CPU architectures. Does that seem right to you?
  - BeeOnRope 8y ago
    Perhaps not, but I was referring only to the assertion that wide SIMD is not in the "hard part" of designing a CPU. I happen to agree with the GP that comparing SIMD accelerated to not can give a misleading picture, and so deserves to be noted - especially when one party has relevant SIMD instructions but they weren't used for some reason.
acdha 8y ago
This depends entirely on what you’re measuring: if my goal is to make my work faster and a compiler can generate something which runs faster, most people don’t feel that it’s not fair to use extra CPU features - they just want to compare the results which they’ll actually get. I remember people whining in the 90s x86/Alpha/POWER comparisons that some compilers were aware of fused Multiply-Add operations, too, but everyone who was trying to make a purchasing decision just tuned them out since they wanted to know realistic FLOPS/$ ratios.

BeeOnRope 8y ago

Well of course SIMD performance is part of the "hard part", because it implies things like very wide cache access, including perhaps unaligned access, high bandwidth between cache levels, wide register files, etc. Plus a sane ISA extension strategy that actually gets people to use your SIMD instructions helps a lot (Intel hasn't done well here, but so far neither has ARM e.g., with almost non-existent support for SVE). SIMD performance is one place that Intel is still fairly far ahead of both AMD and the ARM competition (with Apple far out ahead in that group).

BubRoss 8y ago
I'm not sure what a sane ISA has to do here, the parent was comparing a SIMD accelerated program to a non-SIMD program and using that to compare two CPU architectures. Does that seem right to you?
- BeeOnRope 8y ago
  Perhaps not, but I was referring only to the assertion that wide SIMD is not in the "hard part" of designing a CPU. I happen to agree with the GP that comparing SIMD accelerated to not can give a misleading picture, and so deserves to be noted - especially when one party has relevant SIMD instructions but they weren't used for some reason.

acdha 8y ago

This depends entirely on what you’re measuring: if my goal is to make my work faster and a compiler can generate something which runs faster, most people don’t feel that it’s not fair to use extra CPU features - they just want to compare the results which they’ll actually get. I remember people whining in the 90s x86/Alpha/POWER comparisons that some compilers were aware of fused Multiply-Add operations, too, but everyone who was trying to make a purchasing decision just tuned them out since they wanted to know realistic FLOPS/$ ratios.