11–20 of 278 posts
What's the precision of these ns level measurements?
Clock_gettime(CLOCK_REALTIME) on macos provides nanosecond-level precision.
Is there any performance difference between that and mach_absolute_time() ?
What is the cache line size and page table size in M1? sysconf(_SC_PAGESIZE); /* posix */ Can you get direct processor information like LEVEL1_ICACHE_ASSOC and LEVEL1_ICACHE_LINESIZE from the M1??
`getconf PAGESIZE` returns 16384 on the base M1 MacBook Air. The L1 cache values aren't there. The macOS `getconf` doesn't support -a (listing all variables), so they may just be under a different name. edit: see replies for `sysctl -a` output
Earlier quoted context omitted.
Clock_gettime(CLOCK_REALTIME) on macos provides nanosecond-level precision.
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() ?
macOS also has clock constants for a monotonic clock that increases while sleeping (unlike CLOCK_UPTIME_RAW and mach_absolute_time).
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 processor, we would have done arr[idx] first and waited for it to return, and the processor would realize that it already had arr[idx+1] without having to do the second fetch.
Am I understanding this right?
Earlier quoted context omitted.
`getconf PAGESIZE` returns 16384 on the base M1 MacBook Air. The L1 cache values aren't there. The macOS `getconf` doesn't support -a (listing all variables), so they may just be under a different name. edit: see replies for `sysctl -a` output
Is it possibly exposed via sysctl, which does support a flag to list all variables?
hw.cachelinesize: 128
hw.l1icachesize: 131072
hw.l1dcachesize: 65536
hw.l2cachesize: 4194304
hw.cachelinesize: 64
hw.l1icachesize: 131072
hw.l1dcachesize: 65536
hw.l2cachesize: 4194304For people who know more about this stuff than me: are these sorts optimizations only possible because Apple controls the whole stack and can make the hardware & OS/software perfectly match up with one another or is this something that Intel can do but doesn't for some reasons (tradeoffs)?
Great practical information. Nice to see people who know what they are talking about putting data out there. I hope eventually these persistent HN memes about M1 memory will die: that it's "on-die" (it's not), that it's the only CPU using LPDDR4X-4267 (it's not), or that it's faster because the memory is 2mm closer to the CPU (not that either). It's faster because it has more microarchitectural resources. It can load…
Earlier quoted context omitted.
Clock_gettime(CLOCK_REALTIME) on macos provides nanosecond-level precision.
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() ?
Great practical information. Nice to see people who know what they are talking about putting data out there. I hope eventually these persistent HN memes about M1 memory will die: that it's "on-die" (it's not), that it's the only CPU using LPDDR4X-4267 (it's not), or that it's faster because the memory is 2mm closer to the CPU (not that either). It's faster because it has more microarchitectural resources. It can load…
Why is that strategy simultaneously remarkably efficient and remarkably high-performance? What enabled/led them to make those choices where others haven't?