ARM and Intel have different performance characteristics: a case study
Article is very light on details, and contains zero citations, and only a single result of a single benchmark the guy ran, with no details of how it was run. It follows up by stating his theory as to why this happens as a fact (again with no citations). Author does not even offer us a clue as to what ARM core is used. The claim is:<p><pre><code>  &gt; The difference is that the computation
  &gt; of the most significant bits of a
  &gt; 64-bit product on an ARM processor
  &gt; requires a separate and expensive
  &gt; instruction.
</code></pre>
I see no proof of this anywhere in the ARMv8 spec. You get the lower 64 bits of result using <i>MUL</i> and higher 64 bits using <i>UMULH</i>. Neither of those is that expensive.<p>Looking at [1] we can see that MUL has throughput of 1 and latency of 3, UMULH has 1&#x2F;4 and 6, but as long as you do not issue another multiply just after your UMULH, this 1&#x2F;4 throughput is easily hidden, since only the multiplier is busy, the rest of the CPU can go on. So unless your entire loop is under 6 cycles, or you simply have no instructions to schedule that do not need a multiply within the next 3 of UMULH, it shouldn&#x27;t matter. Given those large constants that need to be loaded, they will each need 4 instrs (mov+movk+movk+movk), there are plenty of instrs to schedule after UMULH. Either OP&#x27;s compiler messed up, or something entirely different is going on.<p>If, the author was using a weaker in-order core, say Cortex-A55, still more performance is expected than appears demonstrated. There [2] the low part is calculated in 2 or 3 cycles, the high in 4. But comparing an ARM in-order little core to a modern OoO x86 is just not fair.<p>EDIT: Indeed, looking [3] at what gcc produces for this code is sad. For example, why it is bothering synthesizing 0x1b03738712fad5c9 before issuing the first UMULH is unclear, but it <i>IS</i> stupid.<p>EDIT2: on skylake [4] MUL has a latency of 3, so faster than on ARM but not by that much. I&#x27;d guess the constant loading on arm using 4 instructions per constant hurts more than UMULH<p>EDIT3: in comments on original site, author said the ARM chip being used is a &quot;Skylark&quot; by &quot;Ampere Computing&quot; [5]. Given that I cannot find any info on that microarchitecture, I cannot say more about why it might be slow.<p>[1] Cortex®-A72 Software Optimization Guide: <a href="https:&#x2F;&#x2F;static.docs.arm.com&#x2F;uan0016&#x2F;a&#x2F;cortex_a72_software_optimization_guide_external.pdf" rel="nofollow">https:&#x2F;&#x2F;static.docs.arm.com&#x2F;uan0016&#x2F;a&#x2F;cortex_a72_software_op...</a><p>[2] Cortex®-A55 Software Optimization Guide: <a href="https:&#x2F;&#x2F;static.docs.arm.com&#x2F;epm128372&#x2F;20&#x2F;arm_cortex_a55_software_optimization_guide_v2.pdf" rel="nofollow">https:&#x2F;&#x2F;static.docs.arm.com&#x2F;epm128372&#x2F;20&#x2F;arm_cortex_a55_soft...</a><p>[3] Godbolt for this code: <a href="https:&#x2F;&#x2F;godbolt.org&#x2F;z&#x2F;UeOo6C" rel="nofollow">https:&#x2F;&#x2F;godbolt.org&#x2F;z&#x2F;UeOo6C</a><p>[4] Lists of instruction latencies, throughputs and micro operation breakdowns for Intel, AMD and VIA CPUs: <a href="https:&#x2F;&#x2F;www.agner.org&#x2F;optimize&#x2F;instruction_tables.pdf" rel="nofollow">https:&#x2F;&#x2F;www.agner.org&#x2F;optimize&#x2F;instruction_tables.pdf</a><p>[5] Skylark - Microarchitectures - AppliedMicro: <a href="https:&#x2F;&#x2F;en.wikichip.org&#x2F;wiki&#x2F;apm&#x2F;microarchitectures&#x2F;skylark" rel="nofollow">https:&#x2F;&#x2F;en.wikichip.org&#x2F;wiki&#x2F;apm&#x2F;microarchitectures&#x2F;skylark</a>