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.

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.

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...

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.

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.

For SIMD it is fairly easily to predict the range of performance of an optimized kernel just based on looking at the micro architecture.

M1 = 4x128

Zen3 = 4x256

Intel = can't make up its mind some are 2x256, others 2x512, and some others are weird combos like (2x256 or 1x512)

M1 on paper looks half throughput compared to Zen3 SIMD per cycle, but because of larger caches and lots of other small advantages it probably closes that margin a little.

Zen3/Intel are also running at higher clock rate, at least on a desktop version.

https://www.sisoftware.co.uk/ is a good benchmark for SIMD code, but it is Windows so no M1 results:(

Source for Zen3 having 4x per cycle? That's impressive and I'd like to read more about it.

Another comment mentioned 4, 2 of which are fma. Works this imply that a matmul kernel for zen3 should have a 2:1 ratio of fmas to mul+add?

There are cases where 8-core Intel/AMD chips beat the 4-core M1, but the reason and solution to that are obvious.

Running x86 code? :)

Funny you should say that but perhaps that's not necessarily true.

https://www.computerworld.com/article/3597949/everything-you...

https://www.imore.com/tests-show-apples-m1-emulates-x86-fast...

Demoscene code in particular... especially demos in the 1K and below (sizecoding) range, which basically amount to very carefully handwritten Asm. I'd expect the x86-to-ARM translation to not do so well in that case, given that it's probably tuned toward typical compiler output.

Depends largely on the code, lots of people show the M1 doing just fine running (translated) x86 code.

Apparently even this is not always the case(!)

https://www.macrumors.com/2020/11/15/m1-chip-emulating-x86-b...

Heat?