Hacker News Reader

Comment by jeffbee | Hacker News Reader

The only microbenchmark I've been able to produce that shows an Intel Tiger Lake as being faster than the M1 (mini) is in atomic primitives. For some reason taking and releasing contended locks is slow on this thing. Unclear if that's only because macOS doesn't have anything that can compete with futex. But all atomics seem slow, not just mutex.

In all other respects the M1 stomps the TGL.

View on HN

That’s interesting considering all the articles I’ve read on this thing indicate the exact opposite. Uncontended atomics are basically free and a huge reason why Swift and ObjC code gets such a huge boost (ARC cost is down significantly).

Traditional POSIX mutexes in MacOS weren’t heavily optimized. When I worked at Apple ~5 years ago they still didn’t have a good futex implementation (not sure if that’s changed since). Generally the OS team doesn’t care because you should be using libdispatch.

Anyway I’d love to read up on where you encountered this claim so I can better understand the countours of how this thing works.

These are my personal observations. You can reproduce, but you'll need to bootstrap the Go toolchain first. For example, in your GOROOT:

  go test -test.bench=Cond2 --test.run=ZZ --test.cpu=1,2,4 sync

For me:

  goos: linux
  goarch: amd64
  pkg: sync
  BenchmarkCond2       3575089        336 ns/op
  BenchmarkCond2-2     3236198        370 ns/op
  BenchmarkCond2-4     2831134        420 ns/op

  goos: darwin
  goarch: arm64
  pkg: sync
  BenchmarkCond2       5903233        190.4 ns/op
  BenchmarkCond2-2       85038      27434 ns/op
  BenchmarkCond2-4     2500750        677.9 ns/op

Way, way worse in the 2- and 4-thread cases on the mac. I don't know why, and the performance of the 2- case swings all over the place.

I would not use a work in progress port of Go to compare. This would be better in C to rule out Go runtime issues.

It probably is in the Go runtime but I tend to look at things at this level. For example if there's some bug in libc++ that's not something I can overlook when evaluating the M1.

There was another comment here that was deleted that accidentally showed the output of running x86-64 go on the M1. That's another weird risk at the user level, that you may unknowingly run the wrong binary through rosetta2 instead of running the native one.

Go f1980efb92c011eab71aa61b68ccf58d845d1de7 on a Mini on 11.0.1

    goos: darwin
    goarch: arm64
    pkg: sync
    BenchmarkCond2       4849542        249.7 ns/op
    BenchmarkCond2-2     2639139        531.1 ns/op
    BenchmarkCond2-4     3112030        393.1 ns/op

Interesting, I can confirm. I wonder if this was the fix.

https://github.com/golang/go/commit/c15593197453b8bf90fc3a90...

Running on Rosetta (and looking like an x86 cpu without fma) is likely a contributing factor, but the M1 was much slower for sums and sums of squares than a Cascadelake (Intel, avx512) cpu here:

https://github.com/chriselrod/VectorizationBase.jl/issues/22

I do a lot of SIMD optimization, so it'll be interesting to see how the M1 competes once there's native support in Julia.

Reply on news.ycombinator.com