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

61–70 of 106 posts

Re: ARM MacBook vs. Intel MacBook

#61

Post by nemothekid »

wait_a_minute wrote: post #41
nemothekid wrote: post #13

Earlier quoted context omitted.

For anyone who doesn’t know who the author is, he has written a ton of high performance code, the most notable being simdjson, fast_float and roaring bitmaps. His performance posts are usually very insightful on things that are usually noise in other contexts (like division). Not excusing the post, but the author has a history of interesting articles

I don't see why this justifies downvoting me, when I have no idea who this person is and their only submission I've seen is extremely scant on anything befitting the title of their post.

FWIW, you weren't downvoted when I responded to your post.

Re: ARM MacBook vs. Intel MacBook

#62

Post by alwillis »

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.

Saying it can process twice as many instructions per clock cycle is an incredibly incorrect statement.

It's not as incredibly incorrect as you may think.

An x86 instruction can be as big as 15 bytes and there's no easy way for the decoder to know where one instruction ends and the next one begins.

All ARM instructions are one size, making instruction decoding more efficient and makes out of order processing faster as well.

More details at https://debugger.medium.com/why-is-apples-m1-chip-so-fast-32...

Re: ARM MacBook vs. Intel MacBook

#63

Post by [deleted] »

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…

[deleted]

Re: ARM MacBook vs. Intel MacBook

#64

Post by TinkersW »

theonemind wrote: post #9

Considering the positive reception of the M1, I'd like to see the cases where the M1 does sorely lose to the Intel chip as the post alludes to. The SIMD sounds promising in that regard, but I don't know processor technology that well. Does anyone know where the Intel chip greatly outdoes the M1?

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:(

Re: ARM MacBook vs. Intel MacBook

#65

Post by sooheon »

cknoxrun wrote: post #48
jaredtn wrote: post #36

Earlier quoted context omitted.

Do all technical advances make you feel sad? Why hang out on Hacker News then?

It's actually a legitimate phenomenon: https://news.ycombinator.com/item?id=15643663

See also Parkinson's law: "Work expands to fill the time available for it's completion"

Re: ARM MacBook vs. Intel MacBook

#66

Post by andy_ppp »

rubicon33 wrote: post #38
breakfastduck wrote: post #33

Earlier quoted context omitted.

Feeling exactly the same. I am trying my hardest to wait for a couple of generations after grabbing a 2019 16".

Same boat. Tough to hold out given these incredible reviews!

I am just going to do it and sell the machine once some absolute best of a machine comes out. 32 firestorm cores please! But still have to decide which one...

Re: ARM MacBook vs. Intel MacBook

#67

Post by jeffbee »

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.

Why wait? I just built node myself, yes it takes a solid hour to compile but it works.

Re: ARM MacBook vs. Intel MacBook

#68

Post by jeffbee »

alwillis wrote: post #62
syberslidder wrote: post #12

Earlier quoted context omitted.

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.

Saying it can process twice as many instructions per clock cycle is an incredibly incorrect statement. It's not as incredibly incorrect as you may think. An x86 instruction can be as big as 15 bytes and there's no easy way for the decoder to know where one instruction ends and the next one begins. All ARM instructions are one size, making instruction decoding more efficient and makes out of order processing faster as…

You keep posting this but it doesn't become more true just by posting it over and over again.

Re: ARM MacBook vs. Intel MacBook

#69

Post by nielsbot »

syberslidder wrote: post #25
syberslidder wrote: post #12

Earlier quoted context omitted.

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.

To follow-up on my own point, once an x86 instruction has been decoded into a micro-op, it gets stored in a micro-op cache, where the vast majority of the frontend spends it's time fetching from. Additionally, "in flight" is a function of frontend width, Reorder buffer size, additional Out of order structures sizes and throughput depends on those plus the retire width. Additionally, IPC alone is a poor metric for per…

How does this square with their relatively low power consumption? (Honestly asking--I don't know about this stuff)

Re: ARM MacBook vs. Intel MacBook

#70

Post by kitsunesoba »

thewebcount wrote: post #56
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…

Man that takes me back, it used to be pretty common to see Mac apps advertise their leverage of AltiVec, even for “consumer” stuff.

It may be entirely imaginary but I always felt like the PowerPC versions of OS X were more responsive than their Intel counterparts, despite running on CPUs that were at a disadvantage in terms of clock speed. I wonder how much of that was due to the PowerPC arch itself.

Post reply on HN