3 ms·

I don't know if that's a valid excuse. Lammps molecular dynamics is by Sandia national labs, they probably have a good ARM implementation. LeelaChessZero is al

I don't know if that's a valid excuse. Lammps molecular dynamics is by Sandia national labs, they probably have a good ARM implementation. LeelaChessZero is also a SIMD-implementation IIRC. Both are SIMD-accelerated, but LeelaChessZero is faster on M2, but LAMMPS is faster on AMD. I don't get it at all. Its really hard to see the pattern. Furthermore, its hard for me to imagine that LAMMPS would be much worse on one system over another, given the authors. --------- Then comes the "in-between" benchmarks. DaCappo is slower on low-power settings for M2, but high-power setting M2 faster than any setting. Very strange behavior, I can't imagine why this would happen. ZSTD compression is faster on AMD, but decompression is faster on M2. Same codebase, same authors, but different results over two different runs.

jinto36 4y ago
I'm not familiar with Zstandard and the Zstandard site doesn't discuss how they use threads in compression vs decompression, but I know that for gzip the parallel implementation in pigz is able to split the workload across threads for compression but not decompression. So it could be that similarly in Zstandard, decompression is not an operation that is identically implemented to compression in reverse. There could be differences in thread utilization that shift the balance to being more sensitive to single-core performance.
GeekyBear 4y ago
> I don't know if that's a valid excuse. It's certainly what Cloudflare found when they were evaluating early ARM server chips. >the first benchmark would be the popular zlib library. At Cloudflare we use an improved version of the library, optimized for 64-bit Intel processors, and although it is written mostly in C, it does use some Intel specific intrinsics. Comparing this optimized version to the generic zlib library wouldn’t be fair. Not to worry, with little effort I adapted the library to work very well on the ARMv8 architecture, with the use of NEON and CRC32 intrinsics. In the process it is twice as fast as the generic library for some files. https://blog.cloudflare.com/arm-takes-wing/ https://blog.cloudflare.com/arm-takes-wing/ SIMD code has to be hand written for both instruction sets before you are comparing Apples to Apples, as it were.
- dragontamer 4y ago
  Does that excuse apply to LAMMPS, a Sandia National Labs highly optimized set of code? Look at the benchmarks in the post. Some are consumer programs, but others are supercomputer programs with an enormous amount of optimization effort put into them for a variety of platforms.
  - GeekyBear 4y ago
    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.

jinto36 4y ago

I'm not familiar with Zstandard and the Zstandard site doesn't discuss how they use threads in compression vs decompression, but I know that for gzip the parallel implementation in pigz is able to split the workload across threads for compression but not decompression. So it could be that similarly in Zstandard, decompression is not an operation that is identically implemented to compression in reverse. There could be differences in thread utilization that shift the balance to being more sensitive to single-core performance.

GeekyBear 4y ago

> I don't know if that's a valid excuse. It's certainly what Cloudflare found when they were evaluating early ARM server chips. >the first benchmark would be the popular zlib library. At Cloudflare we use an improved version of the library, optimized for 64-bit Intel processors, and although it is written mostly in C, it does use some Intel specific intrinsics. Comparing this optimized version to the generic zlib library wouldn’t be fair. Not to worry, with little effort I adapted the library to work very well on the ARMv8 architecture, with the use of NEON and CRC32 intrinsics. In the process it is twice as fast as the generic library for some files. https://blog.cloudflare.com/arm-takes-wing/ https://blog.cloudflare.com/arm-takes-wing/ SIMD code has to be hand written for both instruction sets before you are comparing Apples to Apples, as it were.

dragontamer 4y ago
Does that excuse apply to LAMMPS, a Sandia National Labs highly optimized set of code? Look at the benchmarks in the post. Some are consumer programs, but others are supercomputer programs with an enormous amount of optimization effort put into them for a variety of platforms.
- GeekyBear 4y ago
  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.