17 ms·

Benchmarking division and libdivide on Apple M1 and Intel AVX512

rock_artist 5y ago
I didn't read through the entire thing but... * Would be wise to compare x86_64 under Rosetta as it'll support some AVX translation if I remember correctly. * I didn't see use of Apple's accelerate framework. To comply with ARM64 additional custom Apple magic is within Private extensions / ops that should use higher level frameworks such as Accelerate
- hajile 5y ago
  No AVX support with Rosetta2. Rosetta2 supports up through SSE2. That's the latest instruction set to no longer be patented as of around 2020. They can use x86_64 only because AMD released x86_64 spec in 1999 (even though actual chips came much later).
  - gsnedders 5y ago
    It certainly claims to support many things later than SSE2, including everything up to SEE4.2, on this MacBook Air (M1): % arch -x86_64 sysctl -a | grep machdep.cpu.features machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTSE64 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 AES SEGLIM64
    - creato 5y ago
      I think a more likely explanation is that they supported everything that fits in 128 bit registers (the same as ARM NEON). Trying to emulate code using 256 bit registers on a machine with 128 bit registers is probably difficult and pathologically slow in some cases.
- floatboth 5y ago
  Custom Apple instructions do… matrix stuff IIRC. Not something applicable to simple number division.
  - mhh__ 5y ago
    Has someone actually found out what instructions do what? I assume we won't get to play with them ourselves unless they get the Microsoft treatment over the hidden APIs
    - Someone 5y ago
      There may not be hidden APIs. They could only use those custom instructions inside public functions that everybody can call, such as those in the Accelerate framework.
      - mhh__ 5y ago
        I consider the hidden instructions to be at least close enough to being an API to not bother using another term (AFAICT legally ISA patents aren't considered APIs)
    - ytch 5y ago
      Maybe these: https://gist.github.com/dougallj/7a75a3be1ec69ca550e7c36dc75e0d6f https://gist.github.com/dougallj/7a75a3be1ec69ca550e7c36dc75... https://medium.com/swlh/apples-m1-secret-coprocessor-6599492fc1e1 https://medium.com/swlh/apples-m1-secret-coprocessor-6599492...
torstenvl 5y ago
Great and interesting work! The slowness of division operations is overlooked too often IMHO and is key to (my approach to) avoiding things like integer overflows (there may be a better way than dividing TYPE_MAX by one of the operands but I don't know an alternate technique). Pretty impressive if the M1 really can achieve two-clock-cycle division on a consistent basis. May I offer a nitpicking correction? 1.058ns compared to 6.998ns is an 85% savings, not 88%. The listing you have suggests that going down to 1.058ns is a bigger speed-up than going down to 0.891ns. (PS - Verizon's sale of Yahoo has been in the news lately so I thought of you and the other regulars of the Programming chat room the other day. Hope all is well.)
- david2ndaccount 5y ago
  Depending on what you’re doing, you can usually just use the compiler intrinsics and check for overflow aka, `__builtin_mul_overflow` and similar instead of guarding against it.
  - torstenvl 5y ago
    Useful to know, but if we don't care about portability we can just write a function in assembler that checks the carry or overflow flag or whatever the architecture's equivalent is.
    - mhh__ 5y ago
      https://gcc.gnu.org/wiki/DontUseInlineAsm https://gcc.gnu.org/wiki/DontUseInlineAsm
      - deleted 5y ago
        [deleted]
      - torstenvl 5y ago
        I use compilers other than GCC more often than I use architectures other than x86_64 or aarch64. Using a GCC built-in is less of a good fit for me than using a small .s file in my project. YMMV.
twoodfin 5y ago
I bet there's more than one integer division unit per core. When I've been micro-optimizing performance-critical code, integer division shows up as a hot spot regularly. I assume most developers don't think about the performance implications of coding up a / or % between two runtime values, preventing the compiler from doing any strength reduction. Apple must have seen this in their surely voluminous profiling of real-world applications.
- mhh__ 5y ago
  The fact that Intel and AMD apparently don't prioritize integer division could suggest that their profiling suggests it's not worth it, but with Apple's transistor budget at the moment they can afford it. Also keep in mind that this Xeon might not be really made for number crunching (not really sure)?
  - masklinn 5y ago
    > The fact that Intel and AMD apparently don't prioritize integer division could suggest that their profiling suggests it's not worth it, but with Apple's transistor budget at the moment they can afford it. An other possibility is that Apple has a very different profiling base e.g. iOS applications, whereas Intel and AMD would have more artificial workloads, or be bound by workloads / profiles from scientific computing or the like (video games)?
  - criddell 5y ago
    Would it be fair to characterize the M1 as being made for number crunching?
    - mhh__ 5y ago
      Refining number crunching to mean single threaded performance I would say yes, or at least definitely more so than the Intel chip
    - gameswithgo 5y ago
      Not any more than an intel/amd/etc cpu is. Like that XEON cpu is gonna crunch more numbers, just due to more cores.
mhh__ 5y ago
Some notes: * What's the variance of the measurements? * Per core, the two processors actually (keep in mind based on Intel's TDP figure) have a roughly similar power budget i.e. 205/26 vs. 39/(4 or 8 depending on if you count the bigs, littles or both), so taking into account that the Apple processor is on a process that is something like 4 or 5 times denser it's not that surprising to me that its faster.
GeekyBear 5y ago
Some information from Anandtech's deep dive into Apple's "big" Firestorm core. >On the Integer side, whose in-flight instructions and renaming physical register file capacity we estimate at around 354 entries, we find at least 7 execution ports for actual arithmetic operations. These include 4 simple ALUs capable of ADD instructions, 2 complex units which feature also MUL (multiply) capabilities, and what appears to be a dedicated integer division unit. The core is able to handle 2 branches per cycle, which I think is enabled by also one or two dedicated branch forwarding ports, but I wasn’t able to 100% confirm the layout of the design here. On the floating point and vector execution side of things, the new Firestorm cores are actually more impressive as they a 33% increase in capabilities, enabled by Apple’s addition of a fourth execution pipeline. The FP rename registers here seem to land at 384 entries, which is again comparatively massive. The four 128-bit NEON pipelines thus on paper match the current throughput capabilities of desktop cores from AMD and Intel, albeit with smaller vectors. Floating-point operations throughput here is 1:1 with the pipeline count, meaning Firestorm can do 4 FADDs and 4 FMULs per cycle with respectively 3 and 4 cycles latency. That’s quadruple the per-cycle throughput of Intel CPUs and previous AMD CPUs, and still double that of the recent Zen3, of course, still running at lower frequency. This might be one reason why Apples does so well in browser benchmarks (JavaScript numbers are floating-point doubles). Vector abilities of the 4 pipelines seem to be identical, with the only instructions that see lower throughput being FP divisions, reciprocals and square-root operations that only have an throughput of 1, on one of the four pipes. https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2 https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...
- gsnedders 5y ago
  > This might be one reason why Apples does so well in browser benchmarks (JavaScript numbers are floating-point doubles). Reminder that browsers try to avoid using doubles for the Number type, preferring integers with overflow checks. Much of layout uses fixed point for subpixels, too. Using doubles all the time would be a notable perf regression.
- _kbh_ 5y ago
  One of the reasons Apple does so well in browser tests is that ARM now has instructions to increasing the performance and decreasing the power draw of JavaScript operations.
petermcneeley 5y ago
" Is the hardware divider pipelined, is there more than one per core?" Chaining the divisions (as a series of dependencies) would enable one to see the full latency of a single divide. You could use this data to estimate the number of divide units on the core.
CoastalCoder 5y ago
I'm curious why the author showed the C++ source code, but not the (per-architecture) disassembly. I would think that's a much better starting point for trying to understand the μ-architectural behavior.
- mlindner 5y ago
  Because anyone can plug the C++ into compiler explorer (godbolt) and get a result. He linked to compiler explorer a couple times in the article as well.
  - CoastalCoder 5y ago
    In this particular situation, I'd expect the compiler version and compiler flags really matter. Apologies if I'm overlooking that info, but I can't spot it anywhere in the article.
brigade 5y ago
> Speculatively, AVX512 processes multiplies serially, one 256-bit lane at a time, losing half its parallelism. Sort of, in Skylake AVX512 fuses the 256-bit p0 and p1 together for one 512-bit µop, and p5 becomes 512-bit wide. So theoretically you get 2x 512-bit pipelines versus AVX2's 3x 256-bit pipelines (two of which can do multiplies.) Unfortunately, p5 doesn't support integer multiplies, even in SKUs where p5 does support 512-bit floating-point multiplies. So AVX512 has no additional throughput for integer multiplies on current implementations.
- celrod 5y ago
  p5 can do 512 bit operations, but not 256 bit, e.g. look at Skylake-AVX512 and Cascadelake (Xeon benched in the blog post was Cascadelake) ports for vaddpd: https://uops.info/html-instr/VADDPD_YMM_YMM_YMM.html https://uops.info/html-instr/VADDPD_YMM_YMM_YMM.html Here is 256 bit VPMULUDQ: https://uops.info/html-instr/VPMULUDQ_YMM_YMM_YMM.html https://uops.info/html-instr/VPMULUDQ_YMM_YMM_YMM.html Here is 512 bit VPMULUDQ: https://uops.info/html-instr/VPMULUDQ_ZMM_ZMM_ZMM.html https://uops.info/html-instr/VPMULUDQ_ZMM_ZMM_ZMM.html The 256 bit and 512 bit versions both have a reciprocal throughput of 0.5 cycles/op, using p01 for 256 bit and p05 for 512 bit (where, as you note p0 for 512 bit really means both 0 and 1). So, given the same clock speed, this multiplication should have twice the throughput with 512 bit vectors as with 256 bit. This isn't true for those CPUs without p5, like icelake-client, tigerlake, and rocketlake. But should be true for the Xeon ridiculousfish benchmarked on.
phkahler 5y ago
Phoronix recently did some benchmarks with AVX512 and while it was (modestly if I recall) faster, it was horribly worse in terms of performance per watt. I really hope AMD doesn't adopt AVX512 and if they do I hope it's just the minimum for software compatibility. On a related note, my Ryzen 2400G does not benefit from recompiling code with -march=x86-64-v3 in fact it seems a tiny bit slower. I assume Zen2 and 3 will actually run faster with that option.
- Iwan-Zotow 5y ago
  > I really hope AMD doesn't adopt AVX512 Too late. Zen 4 would have AVX512. > if they do I hope it's just the minimum for software compatibility. Well,that might be the case of AVX512 doing interleaving as 2xAVX2. We'll see
- anfilt 5y ago
  If intel get on a smaller node that would benefit these wide registers energy wise. Like early AVX2 also would downclock, and run hotter. Its one of the reasons the VZEROUPPER instruction exists so the hardware can power down the upper half of these registers when not in use. If recall AVX2 on amd was basical just running 128bit hardware twice till Zen 2. As the nodes get denser i am sure AVX512 will perform better power and heat wise. As for AMD adding support I am sure they will just for compatibility reason.
johnklos 5y ago
There was a time when division was expensive enough to look for alternatives, but nowadays with the M1 it seems that adding even one or two adds or shifts may end up to be more expensive than division. My goodness, how times have changed!
amelius 5y ago
What's the fastest way to implement integer division in hardware?
- pcwalton 5y ago
  I always assumed that CPUs used Newton's method, though that could be wrong. https://en.wikipedia.org/wiki/Division_algorithm#Newton%E2%80%93Raphson_division https://en.wikipedia.org/wiki/Division_algorithm#Newton%E2%8... Edit: Yeah, that's only used for floating point. Looks like integer division is usually an algorithm called SRT: https://en.wikipedia.org/wiki/Division_algorithm#SRT_division https://en.wikipedia.org/wiki/Division_algorithm#SRT_divisio...
  - stephencanon 5y ago
    There are multiple choices used by different implementors. Quadratically convergent iterations like Newton-Raphson and Goldschmidt, and digit-by-digit algorithms like SRT are all common choices represented in mainstream hardware designs and software libraries (for both floating-point and integer).
- zsmi 5y ago
  It's actually a hard question to answer but first one needs to specify the width of the integer and if it is signed or not. Just one semi-random example, dividing two 1b unsigned integers is not going to need the same hardware as dividing two 1024b signed integers.
gigatexal 5y ago
Geez. I wonder if the M2 will just be higher clocked and more cores or if they’ll improve the arch even more?
- sroussey 5y ago
  Yes
- socialdemocrat 5y ago
  Leaked info of M1X suggest slightly higher clock frequency and twice as many high performance cores. But 32GB memory which I think is very welcome for many.
pbsd 5y ago
On Skylake-SP's AVX-512, instructions that previously were dispatched to port 0 or 1 get instead dispatched to ports 0 _and_ 1. So instructions like vpsrlq get zero net speedup from switching to AVX-512 from AVX2. Instructions that previously ran on ports 0,1,5 will now run on ports 0 and 5, for a speedup of at best 1.33. Multiplication will depend on whether the chip has one or two FMA units. If so, you can run vpmuludq on ports 0 and 5, which is a 2x speedup compared to AVX2's ports 0 and 1. This 8275CL Xeon does have 2 FMA units. Looking at the two inner loops, we have up: vmovdqa64 zmm0,ZMMWORD PTR [rdi+rax*4] # p23 add rax,0x10 # p0156 vpmuludq zmm1,zmm0,zmm4 # p05 or only p0 vpsrlq zmm2,zmm1,0x20 # p0 vpsrlq zmm1,zmm0,0x20 # p0 vpmuludq zmm1,zmm1,zmm4 # p05 or only p0 vpandd zmm1,zmm6,zmm1 # p05 vpord zmm1,zmm1,zmm2 # p05 vpsubd zmm0,zmm0,zmm1 # p05 vpsrld zmm0,zmm0,0x1 # p0 vpaddd zmm0,zmm0,zmm1 # p05 vpsrld zmm0,zmm0,xmm5 # p0+p5 vpaddd zmm3,zmm0,zmm3 # p05 cmp rax,rdx jb up up: vmovdqa ymm0,YMMWORD PTR [rdi+rax*4] # p23 add rax,0x8 # p0156 vpmuludq ymm1,ymm0,ymm4 # p01 vpsrlq ymm2,ymm1,0x20 # p01 vpsrlq ymm1,ymm0,0x20 # p01 vpmuludq ymm1,ymm1,ymm4 # p01 vpand ymm1,ymm1,ymm6 # p015 vpor ymm1,ymm1,ymm2 # p015 vpsubd ymm0,ymm0,ymm1 # p015 vpsrld ymm0,ymm0,0x1 # p01 vpaddd ymm0,ymm0,ymm1 # p015 vpsrld ymm0,ymm0,xmm5 # p01+p5 vpaddd ymm3,ymm0,ymm3 # p01 cmp rax,rdx jb up All other things being equal, we have on average, and counting only the differing instructions, a throughput of ~2.27 instructions per cycle on the AVX2 loop, whereas it is somewhere around ~1.45-1.60 for AVX-512, depending whether you have 1 or 2 FMA units to run multiplications on port 5. So based on this approximation, the AVX-512 code should probably run around 2*(1.5/2.27) ~ 1.33 times faster. Add to this that vpmuludq is actually one of the most thermally insensitive instructions around and will reduce your core's frequency by 100-200 MHz, and the small speedup you see is more or less explainable. (I actually do see some more noticeable speedup here when switching to AVX-512; 0.25 vs 0.21). PS: The Intel Icelake and later chips also manage to achieve a throughput of 1/2 divisions per cycle for 32-bit divisors, and 1/3 divisions per cycle for 64-bit divisors. PPS: Some of your functions could use blends. For example, __m256i libdivide_mullhi_u32_vec256_(__m256i a, __m256i b) { __m256i hi_product_0Z2Z = _mm256_srli_epi64(_mm256_mul_epu32(a, b), 32); __m256i a1X3X = _mm256_srli_epi64(a, 32); __m256i hi_product_Z1Z3 = _mm256_mul_epu32(a1X3X, b); return _mm256_blend_epi32(hi_product_0Z2Z, hi_product_Z1Z3, 0xAA); } __m512i libdivide_mullhi_u32_vec512_(__m512i a, __m512i b) { __m512i hi_product_0Z2Z = _mm512_srli_epi64(_mm512_mul_epu32(a, b), 32); __m512i a1X3X = _mm512_srli_epi64(a, 32); __m512i hi_product_Z1Z3 = _mm512_mul_epu32(a1X3X, b); return _mm512_mask_blend_epi32((__mmask16)0xAAAA, hi_product_0Z2Z, hi_product_Z1Z3); }
seumars 5y ago
I’m having a hard time concentrating on the article with that background
- codezero 5y ago
  Funny, what size screen are you on? My wife said the same and tbh I didn't even notice it was a paper towel (funny gag) on my desktop system. I may have just not paid attention. Go into reader mode, the article is great.
- wffurr 5y ago
  I found the hand image quite off putting. Good article though.
pkw792 5y ago
I have just started to use a Mac M1 Mini, and am disappointed. It's incredibly slow to download or install anything. Hangs all the time, takes like 5 hours to install Xcode (it's done but the UI hangs leaving you to believe it has more to do). Hangs when cloning a git repo. Gets stuck anywhere and everywhere. Have to force kill everything and restart to knock some sense into it. I was always respectful of Mac users because Windows has had its problems in the past, but after using a Mac for the first time, I hate it more than ever.
- pkw792 5y ago
  It's very difficult to follow and engage in technical posts like these benchmarking micro-instructions and so on, where on the face of it the product is simply falling on its face in the most basic use-cases.
  - lucian1900 5y ago
    My M1 MacBook Air is by far the fastest machine I’ve ever used. Something is definitely wrong with yours.
  - jasonwatkinspdx 5y ago
    Go to the store. You are not in any way getting the typical experience. This thing is by far the fastest computer I have ever touched in terms of UX responsiveness.
- rangewookie 5y ago
  uhhh... your mac might be broken. I have one and my friend has one. We both engage in cpu/gpu intensive workloads and this just doesn't happen. Still within the return window? Would be interesting to find out your fan is DOA or something like that...
  - pkw792 5y ago
    Yeah it's pretty much brand new and for sure within the return window. Maybe there's something wrong with it. I was expecting cool fireworks for sure, but it's been nothing but a PITA thus far.
lmilcin 5y ago
As somebody who worked for Intel I am deeply ashamed for this result. I mean, seriously, all that tradition and experience and you have a phone company make circles around you on your own field.
- spankyspangler 5y ago
  Well, the roots of the technology came from PA Semi, which was founded with big names who had a long tradition and experience in the industry. They specialized in high performance power efficient processors for embedded, which happens to fit very well with what smartphones need. But their very first design (a PowerPC front end, before Apple bought them) was already quite impressive. Strap a lot of cash and volume behind that after they get bought, and the results speak for themselves. There is no shame in it. Intel has been stumbling at the moment, but others were stumbling in the decade from Core 2 to Skylake.
  - olliej 5y ago
    I mean they acquired PA more than a decade ago now, and have released multiple new generations of chips since then, how long do we keep saying PA is the source of all the performance?
    - spankyspangler 5y ago
      Who is "we"? Did you actually read what I wrote before replying?
- B1FF_PSUVM 5y ago
  > a phone company PA Semi aren't a phone company, they just work for one ... "These guys aren't just going to walk in and ..." (famous last words, LXXXV)
  - kergonath 5y ago
    PA Semi hasn’t been a company for quite some time now. They have joined a team of Apple engineers, and that team has changed quite a bit in the last decade. It currently does not have much in common with PA Semi when it still existed.
oxxoxoxooo 5y ago
Hi fish, thanks for very interesting article, again! Do you think the very fast division on M1 has any implications for 128/64 narrowing division as well? Do you know of a faster way than the method by Moller and Granlund? Do you plan on to include 128/64 division in libdivide? And I asked this question before but the parent post got flagged so I'm trying once more: at the very bottom of the Labor of Division (Episode V) post [1], is it really possible for the second `qhat` (i.e. `q0`) to be off by 2? Do you have any examples of that? [1] https://ridiculousfish.com/blog/posts/labor-of-division-episode-v.html https://ridiculousfish.com/blog/posts/labor-of-division-epis...
- stephencanon 5y ago
  > is it really possible for the second `qhat` (i.e. `q0`) to be off by 2? Yes. I don't have an example in front of me, though. I think there may be one in Knuth vol 2. I'll take a look after toddler bedtime is over =)
- ridiculous_fish 5y ago
  I haven't yet read the Moller and Granlund paper, but its narrowing division using precomputed reciprocal would be a natural fit for libdivide. (libdivide does have a narrowing divide, but it is Algorithm D based). Regarding the second question, it is possible to be off by 2. Consider (base 10) 500 ÷ 59. The estimated quotient qhat is 50 ÷ 5 = 10, but the true digit is 8. So if our partial remainder is 50, we'll be off by 2 in the second digit.
deleted 5y ago
[deleted]
matthewaveryusa 5y ago
In my real world benchmarks I’ve observed the same: the jump from avx2 to Avx512 is usually underwhelming. Is this widely recognized and understood or just anecdotal?
- rbanffy 5y ago
  On the Xeon Phi, IIRC, it was an improvement. When it was added to larger power hungrier cores, it initial required downclocking for thermals, which defeated the purpose somewhat. I hear newer cores can do it with less impactful power limitation measures.
mekpro 5y ago
TLDR The M1 is 10x faster than the Xeon at 64 bit divides. It’s…just wow.
cjohansson 5y ago
Sounds great but being limited to using an Apple OS is a show-stopper issue. I'd rather have a less good processor and using an OS that does not put constraint onto my usage
- minimaul 5y ago
  The Asahi Linux project already has upstreamed basic support, and hardware drivers are now being worked on. It's only a matter of time until M1 macs are practically usable devices on alternative OSes!
  - mhh__ 5y ago
    I don't contend that the time is finite but "usable" given that it's not only Apple hardware but new Apple hardware with from what I've heard slightly janky peripherals, may be relative.
coldtea 5y ago
>libdivide is fish’s library for speeding up integer division by runtime constants. Why would a shell need a library to speed up integer division though? I guess it can be good to have, but for the use case, sounds like overoptimization. Are the returns in speed that good for the use case?
- jakobnissen 5y ago
  I think the author of the library is nicknamed Fish.
  - coldtea 5y ago
    Perhaps, but also the shell he created is named as such. If he referred to himself he could just say "my library for" instead of "fish's library for".
gpderetta 5y ago
If I'm reading this analysis [1] correctly, M1 has only one integer divider, but it appears to be almost fully pipelined as it can indeed start a new divide every other clock cycle. The latency is also impressively good even at 64 bits, but the benchmark should not be div-latency bound in any case as, each division can be started without waiting for the previous division to finish. edit: of course it is possible that internally the divider is not fully pipelined, but there are actually multiple dividers. It is only exposed as a single unit (i.e only a single port) because it wouldn't be able to start more than one operation per clock cycle in any case. If I had to guess, the additional SIMD dividers are repurposed for this, but that doesn't explain why 64 bit still has the same throughput as 32bit. edit2: SIMD is on the same port as fdiv, not integer. fdiv has a throughput of 1 div per clock cycle! [1] https://dougallj.github.io/applecpu/measurements/firestorm/SDIV_fast_32.html https://dougallj.github.io/applecpu/measurements/firestorm/S...
dmayle 5y ago
This is probably the most unusual CPU comparison I've ever seen. The Xeon processor that he's comparing against is a six thousand dollar processor from two years ago that is absolutely destroyed by modern processors that cost less than one eighth of the price. It is expensive because it is designed for 8-processor systems, with 4.5TB memory support, and it runs cores that are glacially slow individually, but meant to make up for it by the massive amount of them (24). Finally, the test is effectively a single-core test, since he's measuring the execution units. I think Apple deserves some kudos for having delivered a chip that would be competitive on the open market (if it were available as such), but all of these ridiculous comparisons just don't paint a picture that has any dose of reality. The M1 is one process node ahead of AMD and two process nodes ahead of Intel. With this advantage, the M1 is performance equivalent[1] to AMD Zen 2 processors (3XXX series, which is one architecture behind) but much more expensive. They are price equivalent[2] to AMD Zen 3 processors, but much slower total performance (though the M1 has about a 25% perf-per-watt lead against the 5600X when limited to the same power envelope). The integrated graphics, however, is a step above. And before I get downvoted to hell, the easiest way to see the actual performance of the M1 as compared to other processors is to look at Apple-to-Apple comparisons (pun partially intended) by comparing benchmarks from an Apple M1 to an Apple Intel, and looking at that same processor off of the Apple platform compared against other processors. If you look at Phoronix Apple M1 to Apple i7-8700B benchmarks (ignoring Rosetta benchmarks since those unfairly favor Intel), you'll see that they perform similarly (in some cases Intel pulls ahead, in some cases the M1 pulls ahead, and in some cases they tie). Then when you compare that 6-core processor to a modern AMD six core processor (5600X), the AMD processor is 33% faster in single-core and 80% faster in multi-core benchmarks. 1. Cut out the synthetic benchmarks, because they are provably biased (e.g. intel biased userbenchmark). Look for application benchmarks that depend on compute, like file compression, or software compiles, or even real-workload browser benchmarks) 2. At MSRP, before current issues with chip availability

I didn't read through the entire thing but... * Would be wise to compare x86_64 under Rosetta as it'll support some AVX translation if I remember correctly. * I didn't see use of Apple's accelerate framework. To comply with ARM64 additional custom Apple magic is within Private extensions / ops that should use higher level frameworks such as Accelerate

hajile 5y ago
No AVX support with Rosetta2. Rosetta2 supports up through SSE2. That's the latest instruction set to no longer be patented as of around 2020. They can use x86_64 only because AMD released x86_64 spec in 1999 (even though actual chips came much later).
- gsnedders 5y ago
  It certainly claims to support many things later than SSE2, including everything up to SEE4.2, on this MacBook Air (M1): % arch -x86_64 sysctl -a | grep machdep.cpu.features machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTSE64 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 AES SEGLIM64
  - creato 5y ago
    I think a more likely explanation is that they supported everything that fits in 128 bit registers (the same as ARM NEON). Trying to emulate code using 256 bit registers on a machine with 128 bit registers is probably difficult and pathologically slow in some cases.
floatboth 5y ago
Custom Apple instructions do… matrix stuff IIRC. Not something applicable to simple number division.
- mhh__ 5y ago
  Has someone actually found out what instructions do what? I assume we won't get to play with them ourselves unless they get the Microsoft treatment over the hidden APIs
  - Someone 5y ago
    There may not be hidden APIs. They could only use those custom instructions inside public functions that everybody can call, such as those in the Accelerate framework.
    - mhh__ 5y ago
      I consider the hidden instructions to be at least close enough to being an API to not bother using another term (AFAICT legally ISA patents aren't considered APIs)
  - ytch 5y ago
    Maybe these: https://gist.github.com/dougallj/7a75a3be1ec69ca550e7c36dc75e0d6f https://gist.github.com/dougallj/7a75a3be1ec69ca550e7c36dc75... https://medium.com/swlh/apples-m1-secret-coprocessor-6599492fc1e1 https://medium.com/swlh/apples-m1-secret-coprocessor-6599492...

torstenvl 5y ago

Great and interesting work! The slowness of division operations is overlooked too often IMHO and is key to (my approach to) avoiding things like integer overflows (there may be a better way than dividing TYPE_MAX by one of the operands but I don't know an alternate technique). Pretty impressive if the M1 really can achieve two-clock-cycle division on a consistent basis. May I offer a nitpicking correction? 1.058ns compared to 6.998ns is an 85% savings, not 88%. The listing you have suggests that going down to 1.058ns is a bigger speed-up than going down to 0.891ns. (PS - Verizon's sale of Yahoo has been in the news lately so I thought of you and the other regulars of the Programming chat room the other day. Hope all is well.)

david2ndaccount 5y ago
Depending on what you’re doing, you can usually just use the compiler intrinsics and check for overflow aka, `__builtin_mul_overflow` and similar instead of guarding against it.
- torstenvl 5y ago
  Useful to know, but if we don't care about portability we can just write a function in assembler that checks the carry or overflow flag or whatever the architecture's equivalent is.
  - mhh__ 5y ago
    https://gcc.gnu.org/wiki/DontUseInlineAsm https://gcc.gnu.org/wiki/DontUseInlineAsm
    - deleted 5y ago
      [deleted]
    - torstenvl 5y ago
      I use compilers other than GCC more often than I use architectures other than x86_64 or aarch64. Using a GCC built-in is less of a good fit for me than using a small .s file in my project. YMMV.

twoodfin 5y ago

I bet there's more than one integer division unit per core. When I've been micro-optimizing performance-critical code, integer division shows up as a hot spot regularly. I assume most developers don't think about the performance implications of coding up a / or % between two runtime values, preventing the compiler from doing any strength reduction. Apple must have seen this in their surely voluminous profiling of real-world applications.

mhh__ 5y ago
The fact that Intel and AMD apparently don't prioritize integer division could suggest that their profiling suggests it's not worth it, but with Apple's transistor budget at the moment they can afford it. Also keep in mind that this Xeon might not be really made for number crunching (not really sure)?
- masklinn 5y ago
  > The fact that Intel and AMD apparently don't prioritize integer division could suggest that their profiling suggests it's not worth it, but with Apple's transistor budget at the moment they can afford it. An other possibility is that Apple has a very different profiling base e.g. iOS applications, whereas Intel and AMD would have more artificial workloads, or be bound by workloads / profiles from scientific computing or the like (video games)?
- criddell 5y ago
  Would it be fair to characterize the M1 as being made for number crunching?
  - mhh__ 5y ago
    Refining number crunching to mean single threaded performance I would say yes, or at least definitely more so than the Intel chip
  - gameswithgo 5y ago
    Not any more than an intel/amd/etc cpu is. Like that XEON cpu is gonna crunch more numbers, just due to more cores.

mhh__ 5y ago

Some notes: * What's the variance of the measurements? * Per core, the two processors actually (keep in mind based on Intel's TDP figure) have a roughly similar power budget i.e. 205/26 vs. 39/(4 or 8 depending on if you count the bigs, littles or both), so taking into account that the Apple processor is on a process that is something like 4 or 5 times denser it's not that surprising to me that its faster.

GeekyBear 5y ago

Some information from Anandtech's deep dive into Apple's "big" Firestorm core. >On the Integer side, whose in-flight instructions and renaming physical register file capacity we estimate at around 354 entries, we find at least 7 execution ports for actual arithmetic operations. These include 4 simple ALUs capable of ADD instructions, 2 complex units which feature also MUL (multiply) capabilities, and what appears to be a dedicated integer division unit. The core is able to handle 2 branches per cycle, which I think is enabled by also one or two dedicated branch forwarding ports, but I wasn’t able to 100% confirm the layout of the design here. On the floating point and vector execution side of things, the new Firestorm cores are actually more impressive as they a 33% increase in capabilities, enabled by Apple’s addition of a fourth execution pipeline. The FP rename registers here seem to land at 384 entries, which is again comparatively massive. The four 128-bit NEON pipelines thus on paper match the current throughput capabilities of desktop cores from AMD and Intel, albeit with smaller vectors. Floating-point operations throughput here is 1:1 with the pipeline count, meaning Firestorm can do 4 FADDs and 4 FMULs per cycle with respectively 3 and 4 cycles latency. That’s quadruple the per-cycle throughput of Intel CPUs and previous AMD CPUs, and still double that of the recent Zen3, of course, still running at lower frequency. This might be one reason why Apples does so well in browser benchmarks (JavaScript numbers are floating-point doubles). Vector abilities of the 4 pipelines seem to be identical, with the only instructions that see lower throughput being FP divisions, reciprocals and square-root operations that only have an throughput of 1, on one of the four pipes. https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2 https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...

gsnedders 5y ago
> This might be one reason why Apples does so well in browser benchmarks (JavaScript numbers are floating-point doubles). Reminder that browsers try to avoid using doubles for the Number type, preferring integers with overflow checks. Much of layout uses fixed point for subpixels, too. Using doubles all the time would be a notable perf regression.
_kbh_ 5y ago
One of the reasons Apple does so well in browser tests is that ARM now has instructions to increasing the performance and decreasing the power draw of JavaScript operations.

petermcneeley 5y ago

" Is the hardware divider pipelined, is there more than one per core?" Chaining the divisions (as a series of dependencies) would enable one to see the full latency of a single divide. You could use this data to estimate the number of divide units on the core.

CoastalCoder 5y ago

I'm curious why the author showed the C++ source code, but not the (per-architecture) disassembly. I would think that's a much better starting point for trying to understand the μ-architectural behavior.

mlindner 5y ago
Because anyone can plug the C++ into compiler explorer (godbolt) and get a result. He linked to compiler explorer a couple times in the article as well.
- CoastalCoder 5y ago
  In this particular situation, I'd expect the compiler version and compiler flags really matter. Apologies if I'm overlooking that info, but I can't spot it anywhere in the article.

brigade 5y ago

> Speculatively, AVX512 processes multiplies serially, one 256-bit lane at a time, losing half its parallelism. Sort of, in Skylake AVX512 fuses the 256-bit p0 and p1 together for one 512-bit µop, and p5 becomes 512-bit wide. So theoretically you get 2x 512-bit pipelines versus AVX2's 3x 256-bit pipelines (two of which can do multiplies.) Unfortunately, p5 doesn't support integer multiplies, even in SKUs where p5 does support 512-bit floating-point multiplies. So AVX512 has no additional throughput for integer multiplies on current implementations.

celrod 5y ago
p5 can do 512 bit operations, but not 256 bit, e.g. look at Skylake-AVX512 and Cascadelake (Xeon benched in the blog post was Cascadelake) ports for vaddpd: https://uops.info/html-instr/VADDPD_YMM_YMM_YMM.html https://uops.info/html-instr/VADDPD_YMM_YMM_YMM.html Here is 256 bit VPMULUDQ: https://uops.info/html-instr/VPMULUDQ_YMM_YMM_YMM.html https://uops.info/html-instr/VPMULUDQ_YMM_YMM_YMM.html Here is 512 bit VPMULUDQ: https://uops.info/html-instr/VPMULUDQ_ZMM_ZMM_ZMM.html https://uops.info/html-instr/VPMULUDQ_ZMM_ZMM_ZMM.html The 256 bit and 512 bit versions both have a reciprocal throughput of 0.5 cycles/op, using p01 for 256 bit and p05 for 512 bit (where, as you note p0 for 512 bit really means both 0 and 1). So, given the same clock speed, this multiplication should have twice the throughput with 512 bit vectors as with 256 bit. This isn't true for those CPUs without p5, like icelake-client, tigerlake, and rocketlake. But should be true for the Xeon ridiculousfish benchmarked on.

phkahler 5y ago

Phoronix recently did some benchmarks with AVX512 and while it was (modestly if I recall) faster, it was horribly worse in terms of performance per watt. I really hope AMD doesn't adopt AVX512 and if they do I hope it's just the minimum for software compatibility. On a related note, my Ryzen 2400G does not benefit from recompiling code with -march=x86-64-v3 in fact it seems a tiny bit slower. I assume Zen2 and 3 will actually run faster with that option.

Iwan-Zotow 5y ago
> I really hope AMD doesn't adopt AVX512 Too late. Zen 4 would have AVX512. > if they do I hope it's just the minimum for software compatibility. Well,that might be the case of AVX512 doing interleaving as 2xAVX2. We'll see
anfilt 5y ago
If intel get on a smaller node that would benefit these wide registers energy wise. Like early AVX2 also would downclock, and run hotter. Its one of the reasons the VZEROUPPER instruction exists so the hardware can power down the upper half of these registers when not in use. If recall AVX2 on amd was basical just running 128bit hardware twice till Zen 2. As the nodes get denser i am sure AVX512 will perform better power and heat wise. As for AMD adding support I am sure they will just for compatibility reason.

johnklos 5y ago

There was a time when division was expensive enough to look for alternatives, but nowadays with the M1 it seems that adding even one or two adds or shifts may end up to be more expensive than division. My goodness, how times have changed!

amelius 5y ago

What's the fastest way to implement integer division in hardware?

pcwalton 5y ago
I always assumed that CPUs used Newton's method, though that could be wrong. https://en.wikipedia.org/wiki/Division_algorithm#Newton%E2%80%93Raphson_division https://en.wikipedia.org/wiki/Division_algorithm#Newton%E2%8... Edit: Yeah, that's only used for floating point. Looks like integer division is usually an algorithm called SRT: https://en.wikipedia.org/wiki/Division_algorithm#SRT_division https://en.wikipedia.org/wiki/Division_algorithm#SRT_divisio...
- stephencanon 5y ago
  There are multiple choices used by different implementors. Quadratically convergent iterations like Newton-Raphson and Goldschmidt, and digit-by-digit algorithms like SRT are all common choices represented in mainstream hardware designs and software libraries (for both floating-point and integer).
zsmi 5y ago
It's actually a hard question to answer but first one needs to specify the width of the integer and if it is signed or not. Just one semi-random example, dividing two 1b unsigned integers is not going to need the same hardware as dividing two 1024b signed integers.

gigatexal 5y ago

Geez. I wonder if the M2 will just be higher clocked and more cores or if they’ll improve the arch even more?

sroussey 5y ago
Yes
socialdemocrat 5y ago
Leaked info of M1X suggest slightly higher clock frequency and twice as many high performance cores. But 32GB memory which I think is very welcome for many.

pbsd 5y ago

On Skylake-SP's AVX-512, instructions that previously were dispatched to port 0 or 1 get instead dispatched to ports 0 _and_ 1. So instructions like vpsrlq get zero net speedup from switching to AVX-512 from AVX2. Instructions that previously ran on ports 0,1,5 will now run on ports 0 and 5, for a speedup of at best 1.33. Multiplication will depend on whether the chip has one or two FMA units. If so, you can run vpmuludq on ports 0 and 5, which is a 2x speedup compared to AVX2's ports 0 and 1. This 8275CL Xeon does have 2 FMA units. Looking at the two inner loops, we have up: vmovdqa64 zmm0,ZMMWORD PTR [rdi+rax*4] # p23 add rax,0x10 # p0156 vpmuludq zmm1,zmm0,zmm4 # p05 or only p0 vpsrlq zmm2,zmm1,0x20 # p0 vpsrlq zmm1,zmm0,0x20 # p0 vpmuludq zmm1,zmm1,zmm4 # p05 or only p0 vpandd zmm1,zmm6,zmm1 # p05 vpord zmm1,zmm1,zmm2 # p05 vpsubd zmm0,zmm0,zmm1 # p05 vpsrld zmm0,zmm0,0x1 # p0 vpaddd zmm0,zmm0,zmm1 # p05 vpsrld zmm0,zmm0,xmm5 # p0+p5 vpaddd zmm3,zmm0,zmm3 # p05 cmp rax,rdx jb up up: vmovdqa ymm0,YMMWORD PTR [rdi+rax*4] # p23 add rax,0x8 # p0156 vpmuludq ymm1,ymm0,ymm4 # p01 vpsrlq ymm2,ymm1,0x20 # p01 vpsrlq ymm1,ymm0,0x20 # p01 vpmuludq ymm1,ymm1,ymm4 # p01 vpand ymm1,ymm1,ymm6 # p015 vpor ymm1,ymm1,ymm2 # p015 vpsubd ymm0,ymm0,ymm1 # p015 vpsrld ymm0,ymm0,0x1 # p01 vpaddd ymm0,ymm0,ymm1 # p015 vpsrld ymm0,ymm0,xmm5 # p01+p5 vpaddd ymm3,ymm0,ymm3 # p01 cmp rax,rdx jb up All other things being equal, we have on average, and counting only the differing instructions, a throughput of ~2.27 instructions per cycle on the AVX2 loop, whereas it is somewhere around ~1.45-1.60 for AVX-512, depending whether you have 1 or 2 FMA units to run multiplications on port 5. So based on this approximation, the AVX-512 code should probably run around 2*(1.5/2.27) ~ 1.33 times faster. Add to this that vpmuludq is actually one of the most thermally insensitive instructions around and will reduce your core's frequency by 100-200 MHz, and the small speedup you see is more or less explainable. (I actually do see some more noticeable speedup here when switching to AVX-512; 0.25 vs 0.21). PS: The Intel Icelake and later chips also manage to achieve a throughput of 1/2 divisions per cycle for 32-bit divisors, and 1/3 divisions per cycle for 64-bit divisors. PPS: Some of your functions could use blends. For example, __m256i libdivide_mullhi_u32_vec256_(__m256i a, __m256i b) { __m256i hi_product_0Z2Z = _mm256_srli_epi64(_mm256_mul_epu32(a, b), 32); __m256i a1X3X = _mm256_srli_epi64(a, 32); __m256i hi_product_Z1Z3 = _mm256_mul_epu32(a1X3X, b); return _mm256_blend_epi32(hi_product_0Z2Z, hi_product_Z1Z3, 0xAA); } __m512i libdivide_mullhi_u32_vec512_(__m512i a, __m512i b) { __m512i hi_product_0Z2Z = _mm512_srli_epi64(_mm512_mul_epu32(a, b), 32); __m512i a1X3X = _mm512_srli_epi64(a, 32); __m512i hi_product_Z1Z3 = _mm512_mul_epu32(a1X3X, b); return _mm512_mask_blend_epi32((__mmask16)0xAAAA, hi_product_0Z2Z, hi_product_Z1Z3); }

seumars 5y ago

I’m having a hard time concentrating on the article with that background

codezero 5y ago
Funny, what size screen are you on? My wife said the same and tbh I didn't even notice it was a paper towel (funny gag) on my desktop system. I may have just not paid attention. Go into reader mode, the article is great.
wffurr 5y ago
I found the hand image quite off putting. Good article though.

pkw792 5y ago

I have just started to use a Mac M1 Mini, and am disappointed. It's incredibly slow to download or install anything. Hangs all the time, takes like 5 hours to install Xcode (it's done but the UI hangs leaving you to believe it has more to do). Hangs when cloning a git repo. Gets stuck anywhere and everywhere. Have to force kill everything and restart to knock some sense into it. I was always respectful of Mac users because Windows has had its problems in the past, but after using a Mac for the first time, I hate it more than ever.

pkw792 5y ago
It's very difficult to follow and engage in technical posts like these benchmarking micro-instructions and so on, where on the face of it the product is simply falling on its face in the most basic use-cases.
- lucian1900 5y ago
  My M1 MacBook Air is by far the fastest machine I’ve ever used. Something is definitely wrong with yours.
- jasonwatkinspdx 5y ago
  Go to the store. You are not in any way getting the typical experience. This thing is by far the fastest computer I have ever touched in terms of UX responsiveness.
rangewookie 5y ago
uhhh... your mac might be broken. I have one and my friend has one. We both engage in cpu/gpu intensive workloads and this just doesn't happen. Still within the return window? Would be interesting to find out your fan is DOA or something like that...
- pkw792 5y ago
  Yeah it's pretty much brand new and for sure within the return window. Maybe there's something wrong with it. I was expecting cool fireworks for sure, but it's been nothing but a PITA thus far.

lmilcin 5y ago

As somebody who worked for Intel I am deeply ashamed for this result. I mean, seriously, all that tradition and experience and you have a phone company make circles around you on your own field.

spankyspangler 5y ago
Well, the roots of the technology came from PA Semi, which was founded with big names who had a long tradition and experience in the industry. They specialized in high performance power efficient processors for embedded, which happens to fit very well with what smartphones need. But their very first design (a PowerPC front end, before Apple bought them) was already quite impressive. Strap a lot of cash and volume behind that after they get bought, and the results speak for themselves. There is no shame in it. Intel has been stumbling at the moment, but others were stumbling in the decade from Core 2 to Skylake.
- olliej 5y ago
  I mean they acquired PA more than a decade ago now, and have released multiple new generations of chips since then, how long do we keep saying PA is the source of all the performance?
  - spankyspangler 5y ago
    Who is "we"? Did you actually read what I wrote before replying?
B1FF_PSUVM 5y ago
> a phone company PA Semi aren't a phone company, they just work for one ... "These guys aren't just going to walk in and ..." (famous last words, LXXXV)
- kergonath 5y ago
  PA Semi hasn’t been a company for quite some time now. They have joined a team of Apple engineers, and that team has changed quite a bit in the last decade. It currently does not have much in common with PA Semi when it still existed.

oxxoxoxooo 5y ago

Hi fish, thanks for very interesting article, again! Do you think the very fast division on M1 has any implications for 128/64 narrowing division as well? Do you know of a faster way than the method by Moller and Granlund? Do you plan on to include 128/64 division in libdivide? And I asked this question before but the parent post got flagged so I'm trying once more: at the very bottom of the Labor of Division (Episode V) post [1], is it really possible for the second `qhat` (i.e. `q0`) to be off by 2? Do you have any examples of that? [1] https://ridiculousfish.com/blog/posts/labor-of-division-episode-v.html https://ridiculousfish.com/blog/posts/labor-of-division-epis...

stephencanon 5y ago
> is it really possible for the second `qhat` (i.e. `q0`) to be off by 2? Yes. I don't have an example in front of me, though. I think there may be one in Knuth vol 2. I'll take a look after toddler bedtime is over =)
ridiculous_fish 5y ago
I haven't yet read the Moller and Granlund paper, but its narrowing division using precomputed reciprocal would be a natural fit for libdivide. (libdivide does have a narrowing divide, but it is Algorithm D based). Regarding the second question, it is possible to be off by 2. Consider (base 10) 500 ÷ 59. The estimated quotient qhat is 50 ÷ 5 = 10, but the true digit is 8. So if our partial remainder is 50, we'll be off by 2 in the second digit.

deleted 5y ago

[deleted]

matthewaveryusa 5y ago

In my real world benchmarks I’ve observed the same: the jump from avx2 to Avx512 is usually underwhelming. Is this widely recognized and understood or just anecdotal?

rbanffy 5y ago
On the Xeon Phi, IIRC, it was an improvement. When it was added to larger power hungrier cores, it initial required downclocking for thermals, which defeated the purpose somewhat. I hear newer cores can do it with less impactful power limitation measures.

mekpro 5y ago

TLDR The M1 is 10x faster than the Xeon at 64 bit divides. It’s…just wow.

cjohansson 5y ago

Sounds great but being limited to using an Apple OS is a show-stopper issue. I'd rather have a less good processor and using an OS that does not put constraint onto my usage

minimaul 5y ago
The Asahi Linux project already has upstreamed basic support, and hardware drivers are now being worked on. It's only a matter of time until M1 macs are practically usable devices on alternative OSes!
- mhh__ 5y ago
  I don't contend that the time is finite but "usable" given that it's not only Apple hardware but new Apple hardware with from what I've heard slightly janky peripherals, may be relative.

coldtea 5y ago

>libdivide is fish’s library for speeding up integer division by runtime constants. Why would a shell need a library to speed up integer division though? I guess it can be good to have, but for the use case, sounds like overoptimization. Are the returns in speed that good for the use case?

jakobnissen 5y ago
I think the author of the library is nicknamed Fish.
- coldtea 5y ago
  Perhaps, but also the shell he created is named as such. If he referred to himself he could just say "my library for" instead of "fish's library for".

gpderetta 5y ago

If I'm reading this analysis [1] correctly, M1 has only one integer divider, but it appears to be almost fully pipelined as it can indeed start a new divide every other clock cycle. The latency is also impressively good even at 64 bits, but the benchmark should not be div-latency bound in any case as, each division can be started without waiting for the previous division to finish. edit: of course it is possible that internally the divider is not fully pipelined, but there are actually multiple dividers. It is only exposed as a single unit (i.e only a single port) because it wouldn't be able to start more than one operation per clock cycle in any case. If I had to guess, the additional SIMD dividers are repurposed for this, but that doesn't explain why 64 bit still has the same throughput as 32bit. edit2: SIMD is on the same port as fdiv, not integer. fdiv has a throughput of 1 div per clock cycle! [1] https://dougallj.github.io/applecpu/measurements/firestorm/SDIV_fast_32.html https://dougallj.github.io/applecpu/measurements/firestorm/S...

dmayle 5y ago

This is probably the most unusual CPU comparison I've ever seen. The Xeon processor that he's comparing against is a six thousand dollar processor from two years ago that is absolutely destroyed by modern processors that cost less than one eighth of the price. It is expensive because it is designed for 8-processor systems, with 4.5TB memory support, and it runs cores that are glacially slow individually, but meant to make up for it by the massive amount of them (24). Finally, the test is effectively a single-core test, since he's measuring the execution units. I think Apple deserves some kudos for having delivered a chip that would be competitive on the open market (if it were available as such), but all of these ridiculous comparisons just don't paint a picture that has any dose of reality. The M1 is one process node ahead of AMD and two process nodes ahead of Intel. With this advantage, the M1 is performance equivalent[1] to AMD Zen 2 processors (3XXX series, which is one architecture behind) but much more expensive. They are price equivalent[2] to AMD Zen 3 processors, but much slower total performance (though the M1 has about a 25% perf-per-watt lead against the 5600X when limited to the same power envelope). The integrated graphics, however, is a step above. And before I get downvoted to hell, the easiest way to see the actual performance of the M1 as compared to other processors is to look at Apple-to-Apple comparisons (pun partially intended) by comparing benchmarks from an Apple M1 to an Apple Intel, and looking at that same processor off of the Apple platform compared against other processors. If you look at Phoronix Apple M1 to Apple i7-8700B benchmarks (ignoring Rosetta benchmarks since those unfairly favor Intel), you'll see that they perform similarly (in some cases Intel pulls ahead, in some cases the M1 pulls ahead, and in some cases they tie). Then when you compare that 6-core processor to a modern AMD six core processor (5600X), the AMD processor is 33% faster in single-core and 80% faster in multi-core benchmarks. 1. Cut out the synthetic benchmarks, because they are provably biased (e.g. intel biased userbenchmark). Look for application benchmarks that depend on compute, like file compression, or software compiles, or even real-workload browser benchmarks) 2. At MSRP, before current issues with chip availability