Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ARM MacBook vs. Intel MacBook

lemire.me

Post reply on HN
Print view View original

51–60 of 106 posts

Re: ARM MacBook vs. Intel MacBook

#51

Post by TinkersW »

GeekyBear wrote: post #4

Anandtech's deep dive into Apple's Firestorm big cores is definitely worth reading if you are interested in how the chips that use their ARM implementation are different. >On the floating point and vector execution side of things, the new Firestorm cores are actually more impressive as they a 33% increase in capabilities, enabled by Apple’s addition of a fourth execution pipeline. The FP rename registers here seem to…

The article is phrased confusingly, at one point saying there are 4 pipelines, and then saying it can do 4 FADDs and 4 FMULs(for a total of 8) per cycle.

So are there 4 or 8?? I believe what they meant to say was 4 FADDs OR 4 FMULs.

Then they say it has quadruple the throughput of Intel and older AMD chips, but that doesn't follow unless this does 8 floating point operations per cycle not 4.

The image of the pipeline only shows 4 so I think this is 4x128 wide, which is good but not going to compete with Zen3 with its wider registers. It is also not quadruple the throughput of Intel or AMD for SIMD..

Re: ARM MacBook vs. Intel MacBook

#52

Post by culturestate »

christoph wrote: post #46
bognition wrote: post #11

Anecdotally I recently grabbed a M1 MacBook Air and it’s an incredible machine. I prefer it over my work issued 2019 pro. It could be that the MDM software has slowed down the pro, but overall the experience with the M1 is very good.

I jumped on the hype train and got a M1 Mac Mini with 16gb and 1TB SSD, as it felt like a steal at around £1k Ex. VAT. for something that reviews told me would be quicker than my MBP. I've been blown away at how much faster/snappier it feels in day to day use compared to my 2018 16GB MBP. With the COVID situation I'm seated at my home office 95% of time now, rather than ~35%. One of the biggest changes has been that…

Have you seen any issues with UI lag? I've been testing an M1 Mini for the same reasons, and connected to a 27" 4K display it feels much less responsive than my Intel MBP with the same monitor.

Re: ARM MacBook vs. Intel MacBook

#53

Post by bfgoodrich »

"The Intel processor has nifty 256-bit SIMD instructions. The Apple chip has nothing of the sort as part of its main CPU. So I could easily come up with examples that make the M1 look bad."

The M1 has 128-bit NEON SIMD, and given its decode pipeline and cache efficiency it seems more likely to actually benefit entirely from it. AVX on Intel devices is often of limited value because it's either memory starved or gets throttled (many SKUs throttle once you start using AVX).

I've had cases where vectorizing ongoing sequential processing in the most optimal fashion available barely gave a single digital percentage increase. 9 times out of 10 it's snake oil.

But regardless, if there's an example that would make the M1 look bad, do it.

Re: ARM MacBook vs. Intel MacBook

#54

Post by arvinsim »

agloeregrets wrote: post #17

What I found shocking is just how drastically faster some workflows are. If you work in JS and Node (say doing unit tests for an angular web app) this machine is so much better it’s unbelievable. It’s probably less than half the time to run tests. Half. It’s real productivity change.

As a JS developer, still waiting for full Homebrew.

But then again, I might as well wait for the next iteration of Apple Silicon if that is the case.

Re: ARM MacBook vs. Intel MacBook

#55

Post by jeffbee »

vlovich123 wrote: post #47
jeffbee wrote: post #29

Earlier quoted context omitted.

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 sinc…

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.

Re: ARM MacBook vs. Intel MacBook

#56

Post by thewebcount »

bfgoodrich wrote: post #53

"The Intel processor has nifty 256-bit SIMD instructions. The Apple chip has nothing of the sort as part of its main CPU. So I could easily come up with examples that make the M1 look bad." The M1 has 128-bit NEON SIMD, and given its decode pipeline and cache efficiency it seems more likely to actually benefit entirely from it. AVX on Intel devices is often of limited value because it's either memory starved or gets…

This is one of the things I missed about AltiVec from the PPC days. They really designed it nicely. It was a different set of registers that worked normally. The permute instructions were very useful! When trying to port AltiVec code to Intel SSE at the time, it would often come out worse because of all the constraints. You couldn't intermix floating point and SSE code because they used the same registers. There were stalls if you did as it switched back and forth. A friend actually hired Intel engineers to port his AltiVec code to Intel at the time and even they couldn't make it work as fast as it was on his PPC Mac. So I'm hoping the Neon instructions bring back some of the elegance and sanity we had in the PPC/AltiVec days.

Re: ARM MacBook vs. Intel MacBook

#57

Post by yxhuvud »

syberslidder wrote: post #12
alwillis wrote: post #5

The M1 has 8 instruction decoders while every Intel processor maxes out at 4. This enables many more instructions in flight than on Intel. The M1 can process twice as many instructions per clock cycle than an x86 processor can.

4 x86 decoders, all modern x86 CPUs have micro-op caches that are wider than 4 and the retire width of the machines are 6 or greater. Saying it can process twice as many instructions per clock cycle is an incredibly incorrect statement.

Not necessarily. The problem is that it doesn't mean anything because they have different instruction sets. That makes comparing ipc pretty useless.

Re: ARM MacBook vs. Intel MacBook

#58

Post by shepherdjerred »

arvinsim wrote: post #54
agloeregrets wrote: post #17

What I found shocking is just how drastically faster some workflows are. If you work in JS and Node (say doing unit tests for an angular web app) this machine is so much better it’s unbelievable. It’s probably less than half the time to run tests. Half. It’s real productivity change.

As a JS developer, still waiting for full Homebrew. But then again, I might as well wait for the next iteration of Apple Silicon if that is the case.

You can install ARM and x86 Homebrew side-by-side. It works really well.

When I set up my M1 mac I compiled as much as I could from source using the ARM Homebrew, and for everything else I installed it via the x86 Homebrew.

Re: ARM MacBook vs. Intel MacBook

#59

Post by bognition »

culturestate wrote: post #52
christoph wrote: post #46

Earlier quoted context omitted.

I jumped on the hype train and got a M1 Mac Mini with 16gb and 1TB SSD, as it felt like a steal at around £1k Ex. VAT. for something that reviews told me would be quicker than my MBP. I've been blown away at how much faster/snappier it feels in day to day use compared to my 2018 16GB MBP. With the COVID situation I'm seated at my home office 95% of time now, rather than ~35%. One of the biggest changes has been that…

Have you seen any issues with UI lag? I've been testing an M1 Mini for the same reasons, and connected to a 27" 4K display it feels much less responsive than my Intel MBP with the same monitor.

I have a 27” 4K Dell that connects over USB-C and haven’t seen any lagging

Re: ARM MacBook vs. Intel MacBook

#60

Post by st3fan »

jeffbee wrote: post #55
vlovich123 wrote: post #47

Earlier quoted context omitted.

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 sinc…

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 Be…

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.
Post reply on HN