News for hackers. Stuff that matters.
Re:Memory access on the Apple M1 processor by titzer on Wednesday January 06, 2021 @02:07PM (#25661007)
> it can do with a single core what an Intel part needs all cores to accomplish.

Care to explain what you mean specifically by this?

Re:Memory access on the Apple M1 processor by saagarjha on Wednesday January 06, 2021 @02:26PM (#25661198)
The M1 has extremely high single-core performance.
Re:Memory access on the Apple M1 processor by temac on Wednesday January 06, 2021 @02:31PM (#25661246)
It is not 4 times faster than an Intel core, though...
Re:Memory access on the Apple M1 processor by saagarjha on Wednesday January 06, 2021 @03:07PM (#25661625)
It is in memory performance, which is what I assumed was being measured here.
Re:Memory access on the Apple M1 processor by kllrnohj on Wednesday January 06, 2021 @03:21PM (#25661846)
How are you defining memory performance and where are your supporting comparisons? This article only discusses the M1's behavior, and makes no comparisons to any other CPU.
Re:Memory access on the Apple M1 processor by FabHK on Wednesday January 06, 2021 @04:22PM (#25662685)
FWIW, I ran it on a MacBook Pro (13-inch, 2019, Four Thunderbolt 3 ports), 2.4 GHz Quad-Core Intel Core i5, 8 GB 2133 MHz LPDDR3:

  two  : 49.6 ns  (x 5.5)
  two+ : 64.8 ns  (x 5.2)
  three: 72.8 ns  (x 5.6)
EDIT to add: above was just `cc`. Below is with `cc -O3 -Wall`, as in Lemire's article:

  two  : 62.8 ns  (x 7.1)
  two+ : 69.2 ns  (x 5.5)
  three: 95.3 ns  (x 7.3)
Re:Memory access on the Apple M1 processor by namibj on Wednesday January 06, 2021 @04:53PM (#25663106)
You _need_ to use -mnative because it otherwise retains backwards compatibility to older x86.
Re:Memory access on the Apple M1 processor by FabHK on Wednesday January 06, 2021 @06:00PM (#25663901)

  (base) Coding % cc -mnative two-three.c
  clang: error: unknown argument: '-mnative'

  (base) Coding % cc -v
  Apple clang version 12.0.0 (clang-1200.0.32.28)
  Target: x86_64-apple-darwin20.2.0
  Thread model: posix
Re:Memory access on the Apple M1 processor by astrange on Wednesday January 06, 2021 @09:23PM (#25666500)
It's spelled "-march=native" in gcc and "-arch x86_64h" in clang.

It doesn't make much difference though, autovectorization doesn't work very well and there is not a lot of special optimization for newer x86 CPUs.

Re:Memory access on the Apple M1 processor by namibj on Thursday January 07, 2021 @10:05PM (#25681042)
All recent Intel Core-i microarchitectures require using full vector width loads to max out L1d bandwidth, because the load/store units don't actually care about the width of a load, as long as it doesn't cross a cache line (in which case the typical penalty is an additional cycle).

Only using 128 bit wide instructions on a core that has 512 bit hardware results in 4x less L1d bandwidth.

Re:Memory access on the Apple M1 processor by africanboy on Wednesday January 06, 2021 @05:46PM (#25663736)
there must be something wrong there, on my late 2014 laptop that mounts

    Type: DDR4
    Speed: 2133 MT/s
I get

    two  : 27.1 ns (3x)
    two+ : 28.6 ns (2.2x)
    three: 39.7 ns (3x)
which is not much, considering this is an almost 6 years old system with 2x slower memor
Re:Memory access on the Apple M1 processor by FabHK on Wednesday January 06, 2021 @06:06PM (#25663970)
Dunno, I didn't reboot and didn't close all other programs (browser, editor, mail, calendar, notes, editor)... Top shows

Load Avg: 2.36, 2.01, 1.97 CPU usage: 2.10% user, 3.39% sys, 94.49% idle

Re:Memory access on the Apple M1 processor by titzer on Wednesday January 06, 2021 @02:43PM (#25661364)
Sure, and it has a very large out-of-order execution engine, but it is not fundamentally different from what other super scalar processors do. So I am curious what the OP meant by that offhand comment.
Re:Memory access on the Apple M1 processor by jeffbee on Wednesday January 06, 2021 @03:05PM (#25661582)
One core of the M1 can drive the memory subsystem to the rails. A single core can copy (load+store) at 60GB/s. This is close to the theoretical design limit for DDR4X. A single core on Tiger Lake can only hit about 34GB/s, and Skylake-SP only gets about 15GB/s. So yes, it is close to 4x faster.
Re:Memory access on the Apple M1 processor by titzer on Wednesday January 06, 2021 @03:21PM (#25661840)
Thanks for clarifying. But this isn't any fundamental difference IMO. There isn't any functional limitation in an Intel core that means it cannot saturate the memory bandwidth from a single core, unless I am missing something.
Re:Memory access on the Apple M1 processor by nkurz on Wednesday January 06, 2021 @08:17PM (#25665900)
One could argue that it's not "fundamental", but it's definitely a functional limitation of the current Intel cores. The memory bandwidth of a single core is hardware limited by the number "Line Fill Buffers". Each buffer keeps track of one outstanding L1 cacheline miss, thus the number of LFB's limits the memory level parallelism (MLP). "Little's Law" gives the relationship between the latency, outstanding requests, and throughput. With 10 LFB's and the current latency of memory, it's physically impossible for a single core to use all available memory bandwidth, especially on machines with more than 2 memory channels.

The M1 chip allows higher MLP, presumably because it has more LFB's per core (or maybe they are using different approach where the LFB's are not per-core?). I apologize for using so many abbreviations. I searched to try to find a better intro, but didn't find anything perfect. I did come across this thread that (apparently) I started several years ago at the point where I was trying to understand what was happening: https://community.intel.com/t5/Software-Tuning-Performance/S....

Re:Memory access on the Apple M1 processor by AnbeSivam on Thursday January 07, 2021 @03:00AM (#25668489)
Came across someone else mentioning the similar bandwidth constraint w.r.to LFB per core a month back.

https://news.ycombinator.com/item?id=25221968

Re:Memory access on the Apple M1 processor by jeffbee on Wednesday January 06, 2021 @03:23PM (#25661880)
I agree, it's not fundamental. It is, in particular, not that other popular myth, that it's "because ARM". It's only that 1 core on an Intel chip can have N-many outstanding loads and 1 core of an M1 can have M>N outstanding loads.