4 ms·

If both code bases have had the same level of hand-optimization for the instruction set they run on. For instance, in the example above, Cloudflare doubled the

If both code bases have had the same level of hand-optimization for the instruction set they run on. For instance, in the example above, Cloudflare doubled the speed of the code by taking advantage of ARM specific instructions in the same way they had previously optimized their code for x86 specific instructions. Of course, using the availible instructions isn't the same thing as putting in a heavy investment of time to make the code as efficient as possible. As an example, look at x86 AV1 video encoders. The early ones were incredibly slow, but through many iterations of hand written SIMD code, recent versions have been getting much faster on the same hardware.

dragontamer 4y ago
SIMD compute isn't a mysterious kind of beast though. ARM / Apple M2 here is just 128-bit vectors. AMD / Intel AVX is 256-bit vectors, which is harder to optimize for (!!) due to the increased parallelism. NEON itself is kinda crappy, missing a few good data-movement instructions (pshufb doesn't exist in ARM world), but IIRC, there are hard-coded swizzles in NEON that reach high levels of performance. So in this case, its simply easier to write pshufb style code in Intel/AMD systems. Then again, I don't expect that a BLAS library would use pshufb too much. So you'd probably just have a simple dot-product like vector going up-and-down RAM to maximize your matrix-multiplication speeds. ---------- That's what I mean. LAMMPS isn't "easy" but it should fundamentally be a matrix multiplication (which is highly studied, and well optimized on all platforms). Indeed, the best performing BLAS libraries these days are on NVidia, not Intel or ARM for that matter. (Though Intel's AVX512 matrix multiplications are probably next best, they don't apply to this Apple vs AMD comparison). You can't just assume a problem exists in general. There's some benchmarks in here that are sufficiently well optimized in ARM yet still come out better for the AMD chips. And vice versa for that matter (I'd expect LeelaZero to favor AMD, so I was surprised to see it better on the Apple M2). --------- Assuming a Russell's Teapot just because there was a teapot from an unrelated benchmark years ago is kind of a bad form of argument. SIMD-compute (AVX, NEON, SVE, etc. etc.) has become more popular today, and there are more NEON_optimized libraries today than even just 5 years ago. And there are plenty of applications in this Phoronix benchmark where we'd reasonably expect good ARM-NEON optimizations.
- GeekyBear 4y ago
  > SIMD compute isn't a mysterious kind of beast though. I'm reminded of the Handbrake people back in 2018 telling users that the current open source implementations of AV1 encoder ran 6,000 times slower than h.264 encode, and that they wouldn't be adding support for AV1 encode anytime soon, as the code base needed time to be optimized. See here: https://github.com/HandBrake/HandBrake/issues/457 https://github.com/HandBrake/HandBrake/issues/457 Just because you run on a particular instruction set doesn't mean you're using that instruction set in an optimal manner.

dragontamer 4y ago

SIMD compute isn't a mysterious kind of beast though. ARM / Apple M2 here is just 128-bit vectors. AMD / Intel AVX is 256-bit vectors, which is harder to optimize for (!!) due to the increased parallelism. NEON itself is kinda crappy, missing a few good data-movement instructions (pshufb doesn't exist in ARM world), but IIRC, there are hard-coded swizzles in NEON that reach high levels of performance. So in this case, its simply easier to write pshufb style code in Intel/AMD systems. Then again, I don't expect that a BLAS library would use pshufb too much. So you'd probably just have a simple dot-product like vector going up-and-down RAM to maximize your matrix-multiplication speeds. ---------- That's what I mean. LAMMPS isn't "easy" but it should fundamentally be a matrix multiplication (which is highly studied, and well optimized on all platforms). Indeed, the best performing BLAS libraries these days are on NVidia, not Intel or ARM for that matter. (Though Intel's AVX512 matrix multiplications are probably next best, they don't apply to this Apple vs AMD comparison). You can't just assume a problem exists in general. There's some benchmarks in here that are sufficiently well optimized in ARM yet still come out better for the AMD chips. And vice versa for that matter (I'd expect LeelaZero to favor AMD, so I was surprised to see it better on the Apple M2). --------- Assuming a Russell's Teapot just because there was a teapot from an unrelated benchmark years ago is kind of a bad form of argument. SIMD-compute (AVX, NEON, SVE, etc. etc.) has become more popular today, and there are more NEON_optimized libraries today than even just 5 years ago. And there are plenty of applications in this Phoronix benchmark where we'd reasonably expect good ARM-NEON optimizations.

GeekyBear 4y ago
> SIMD compute isn't a mysterious kind of beast though. I'm reminded of the Handbrake people back in 2018 telling users that the current open source implementations of AV1 encoder ran 6,000 times slower than h.264 encode, and that they wouldn't be adding support for AV1 encode anytime soon, as the code base needed time to be optimized. See here: https://github.com/HandBrake/HandBrake/issues/457 https://github.com/HandBrake/HandBrake/issues/457 Just because you run on a particular instruction set doesn't mean you're using that instruction set in an optimal manner.