Memory access on the Apple M1 processor

Post by duskwuff » Wed, Jan 06, 2021, 7:07 PM UTC

jayd16 wrote: post #25

djacobs7 wrote: post #15

Is the article saying that the M1 is slower than we would have expected in this case? My understanding, based on the article, is that a normal processor, we would have expected arr[idx] + arr[idx+1] and arr[idx] to take the same amount of time. But the M1 is so parallelized that it goes to grab both arr[idx] and arr[idx+1] separately. So we have to wait for both of those two return. Meanwhile, on a less parallelized…

Its a little confusing because they're conflating the idea that you almost certainly read at least the entire word (and not a single byte) at a time with the other idea that you could fetch multiple words concurrently.

Post by saagarjha » Wed, Jan 06, 2021, 7:10 PM UTC

lilyball wrote: post #14

geocar wrote: post #11

Earlier quoted context omitted.

I seem to recall OSX didn't used to have clock_gettime, so it's news to me that it even exists -- I might have been away from OSX too long. Is there any performance difference between that and mach_absolute_time() ?

It was added some years ago, and I believe mach_absolute_time is actually now implemented in terms of (the implementation of) clock_gettime. The documentation on mach_absolute_time now even says you should use clock_gettime_nsec_np(CLOCK_UPTIME_RAW) instead. macOS also has clock constants for a monotonic clock that increases while sleeping (unlike CLOCK_UPTIME_RAW and mach_absolute_time).

  _mach_absolute_time:
  00000000000012ec        pushq   %rbp
  00000000000012ed        movq    %rsp, %rbp
  00000000000012f0        movabsq $0x7fffffe00050, %rsi   ## imm = 0x7FFFFFE00050
  00000000000012fa        movl    0x18(%rsi), %r8d
  00000000000012fe        testl   %r8d, %r8d
  0000000000001301        je      0x12fa
  0000000000001303        lfence
  0000000000001306        rdtsc
  0000000000001308        lfence
  000000000000130b        shlq    $0x20, %rdx
  000000000000130f        orq     %rdx, %rax
  0000000000001312        movl    0xc(%rsi), %ecx
  0000000000001315        andl    $0x1f, %ecx
  0000000000001318        subq    (%rsi), %rax
  000000000000131b        shlq    %cl, %rax
  000000000000131e        movl    0x8(%rsi), %ecx
  0000000000001321        mulq    %rcx
  0000000000001324        shrdq   $0x20, %rdx, %rax
  0000000000001329        addq    0x10(%rsi), %rax
  000000000000132d        cmpl    0x18(%rsi), %r8d
  0000000000001331        jne     0x12fa
  0000000000001333        popq    %rbp
  0000000000001334        retq

Post by mtgx » Wed, Jan 06, 2021, 7:10 PM UTC

gameswithgo wrote: post #23

pdpi wrote: post #20

Earlier quoted context omitted.

This seems to be a recurring theme with the M1, and one that, in a sense, actually baffles me even more than the alternative. There is no "magic" at play here, it's just lots and lots of raw muscle. They just seem to have a freakishly successful strategy for choosing what aspects of the processor to throw that muscle at. Why is that strategy simultaneously remarkably efficient and remarkably high-performance? What en…

I see two main things behind it: 1. they are the only ones who have 5nm chips because they paid a lot to TSMC for that right 2. they gave up on expandable memory, which lets them solder it right next to the cpu, which likely makes it easier to ship with really high clocks. and/or they just spent the money it takes to get binned lpddr4 at that speed. So a good cpu design, just like AMD and Intel have, but one generati…

Post by africanboy » Wed, Jan 06, 2021, 7:12 PM UTC

SekstiNi wrote: post #26

phkahler wrote: post #21

Earlier quoted context omitted.

>> My understanding, based on the article, is that a normal processor, we would have expected arr[idx] + arr[idx+1] and arr[idx] to take the same amount of time. That depends. If the two accesses are on the same cache line, then yes. But since idx is random that will not happen sometimes. He never says how big array[] is in elements or what size each element is. I thought DRAM also had the ability to stream out conse…

> There's not enough info to figure out what's going on. If you only look at the article this is true. However, the source code is freely available: https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/...

Post by jayd16 » Wed, Jan 06, 2021, 7:17 PM UTC

wrsh07 wrote: post #29

Ok, summary: This article lays out three scenarios: 1) accessing two random elements 2) accessing 3 random elements 3) accessing two pairs of adjacent elements (same as (1) but also the elements after each random element) It then does some trivial math to use the loaded data. A naive model might only consider memory accesses and might assume accessing an adjacent element is free. On the Mac m1 core, this is not the c…