ARM MacBook vs. Intel MacBook | Hacker News Reader

ARM MacBook vs. Intel MacBook

lemire.me

102 pointsnnx100 comments

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 land at 384 entries, which is again comparatively massive. The four 128-bit NEON pipelines thus on paper match the current throughput capabilities of desktop cores from AMD and Intel, albeit with smaller vectors. Floating-point operations throughput here is 1:1 with the pipeline count, meaning Firestorm can do 4 FADDs and 4 FMULs per cycle with respectively 3 and 4 cycles latency. That’s quadruple the per-cycle throughput of Intel CPUs and previous AMD CPUs, and still double that of the recent Zen3, of course, still running at lower frequency. This might be one reason why Apples does so well in browser benchmarks (JavaScript numbers are floating-point doubles).

Vector abilities of the 4 pipelines seem to be identical, with the only instructions that see lower throughput being FP divisions, reciprocals and square-root operations that only have an throughput of 1, on one of the four pipes.

https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...

I like Apple's approach of having more narrow vector units rather than a few extremely wide ones. Narrower vector units are generally easier to program and easier to support on small cores (like the efficiency cores). It's a good tradeoff for cores used outside of niche applications that do a ton of numerical calculations.

Compare this to a design like AVX/AVX2 that has wider 256-bit vectors, but almost always forces the programmer to treat them as two 128-bit vectors glued together. All because Intel realized they had to power down half of each vector ALU to save power at idle.

Of course, the future is hopefully more flexible vector ISAs like SVE. AVX-512 is not too bad either today, but Intel seems almost pathologically opposed to making forward-looking decisions (what about when they want to double the vector width again??).

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

Each is a multiply-accumulate instruction: https://developer.arm.com/documentation/dui0473/latest/neon-...

They probably are FMA ports, but they didn't say that anywhere in the article, and it still doesn't explain the "quadruple the throughput", as both of Intels ports are FMA and 2/4 of AMDs are FMA.

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.

And this is via Rosetta 2?

You can build node for the M1.

I was using Native Node built from source.

Great, now that we have this new fast hardware, time for developers to make everything 2x slower again.

It's not far from reality; suddenly there's 100% more capacity for analytics and behavioral tracking.

God I hate this timeline.

Then opt out of it by blocking all that tracking and those analytics as well as those spurious a/b tests. While you're at it you might as well block any and all "social functionality". This way they get to play with their new toys without bothering you.

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"

Also the famous Jevons paradox.

Blinn’s Law

“As technology advances, the rendering time remains constant.”

https://www.fxguide.com/fxfeatured/founders-series-industry-...

Not all but software related in general and Javascript/Electron related in particular any advance make me sad. I hang out on HN to find comfort in fact that others also feel crappy software hosing all the hardware advances.

Remember what happened with the last great speed increase from spinners to SSD. They speed up was as dramatic as the bloat added in the past decade to slow it down. One of the worst offenders is Apple though.

maybe more people will starting writing twice as many tests!

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.

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

On older platforms(High Sierra), brew builds from source most of the time and I just built node(latest) on a i5 MacMini 2011. It took 76 minutes.

Oh god. You are going to hate this. Node v15 on my MacBook Air built in 20 minutes.

Oh no, not at all, in fact for an entry level Mini of almost 10 years it's not bad at all.

Or you can try MacPorts which already supports ARM ;)

https://www.macports.org/

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?

Running x86 code? :)

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

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.

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.

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.

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

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?

Heat?

Was expecting a bit more than a handful of paragraphs and three tests from this article.

Ditto, this seems like clickbait to route us to Yet Another Blog.

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.

I don't think the person who submitted it is the original writer.

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

He could have copy/pasted some of his code on Github as 'filler'

I'm sure there are some around that would prefer this bit of terse review. There are less words in this tech review than in most "when I was a kid, mom would make us this" type of story before you can ever get to the actual recipe.

I think he wanted more content, more tests, not more words.

People on HN still want to talk about the M1. It's just such an exciting product. So this will still sit on the front page for a while, despite the relatively terse source material.

It is more of an interesting trend than it is an "exciting product". Once upscaled ARM processors and/or SoCs become available for use in other- or non-branded products it will become truly exciting as that will open up for breaking the AMD64 hegemony in the server and PC spaces. They will be supported by Linux, Windows and others which is essential for the viability of a new platform.

Yep, given the URL :)

Just run the author's benchmark program on my i5-9600k:

    |          | i5-9600k     | i7-7700HQ | Apple M1  |  
    |strtod    | 217.97 MB/s  | 80 MB/s   | 115 MB/s  |  
    |abseil    | 613.48 MB/s  | 460 MB/s  | 580 MB/s  |  
    |fastfloat | 1400.15 MB/s | 1000 MB/s | 1800 MB/s |

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.

It's excellent. I have the 8-core i9 16" Pro and I prefer the Air in every way for development. The keyboard is better (no touchbar), it doesn't get as hot, the battery life is better, it's faster, and it cost 1/4 as much ($999 vs about $4k). I bought the 16" in February, only 10 months ago.

What a leap.

I've been using my girlfriend's M1 Air, and I am superbly impressed. You can feel how much more responsive the system is with every click. I am so tempted to upgrade my from my 2017 Pro. The only thing holding me back is the knowledge that the M1 is the slowest Macintosh chip Apple will ever make.

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!

It's not even that expensive, so it's a much easier product to recommend.

Compare to the 2012 MBPr, a similarly innovative Apple laptop. The 2012 was $2,199 in 2012 dollars (nearly $2,500 today). This is that kind of leap, and more. $999 (sometimes $899) is a bargain.

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

Agreed; I received my new m1 mba this week and it is _nice_. Anyone reading who is on the fence, I don't think you'll regret getting one (and I say that as a cheap bastard unix greybeard in general, heh). Cool-running, quiet, good keyboard, gorgeous display, insane battery life, it's just a phenomenal machine. :)

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 instead of having a jet engine level of noise next to me most of the day now, I have something that I haven't heard a noise from once in three or four days. It takes up way less desk space as well. It's much easier to tuck away somewhere than a laptop which you always have an emotional connection to needing portability with. I've had Photoshop, Illustrator, Media Encoder running encodes, After Effects, loads of web tabs open and it still feels cold to touch. More desk space, faster, less noise, less heat. It's ticked all those boxes.

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

It could be a USB-C adapter issue if you are using HDMI. Just try different adapters until you find one that works well with your monitors.

I don't understand why Apple doesn't make a high-end multi port USB-C dock after all these years. Third-party quality isn't consistent.

I'm running two LG 34" ultra wides off it and I've not noticed anything to aggravate me, but maybe I'm just not that susceptible, I'm generally pretty forgiving having spent hundreds of hours doing VR dev work. I think my brain has become somewhat immune to visual lag effects. The one issue I have had is that one of the monitors on USB-C (HDMI connected monitor has always been fine) seems have some sort of bug waking up sometimes, that I can only solve by powering it off and back on. Irritating. Not sure if it's the monitor or the Mac. I'd say the Mac, as I never had this issue with the MBP.

Also, the colour profile/difference between two identical monitors, one connected on HDMI, one on USB-C was startling. No idea why... I had to spend 20 minutes with Apples advanced calibration tool get them to match up. Even selecting the same colour profiles on both monitors gave a staggering difference in colour representation which I found very odd.

Good effort by the author. I was expecting to see a bit more elaborate benchmarks, to be honest. I had a look at M1 Macbook Air yesterday at the local store. Everything felt snappy and the display is brilliant. I'd go for at least 16 gigs of RAM. I'd probably wait for the 2nd iteration as well.

The only reason I would want more than 16gb RAM is for more room for virtual machines, so without that and it being cheaper than worse machines this is a hard yes, buy.

BUT the possibility of familiar OS' coming out with ARM versions (or just the x86 versions being emulated well), and the possibility of a more powerful M1-style processor with more than 16gb RAM anyway makes me want to wait.

But honestly if they roll out a better processing still with only 16gb RAM I guess I'll pull the trigger on one of the models.

I hope the next batch of laptops will allow at least 32GB. I was going to replace the 2015 MBA I'm typing on now with this new one, but after seeing how well games - even unoptimized ones like Cities:Skylines run on the current MBA I started to consider that perhaps I could abandon my Windows gaming machine and just go full time Mac.

But I subscribe to far too many mods in Cities:Skylines to get away with 16GB of RAM - unfortunately.

This MBA is way past expiration date so hopefully I don't have to wait more than six months (I suspect a fairly safe bet).

I'm one of the 2015 MBP holdouts

I'm almost there. I always liked the newer form factor and my main plan was to wait for USB-C to become more prominent, and as a bonus Apple even got rid of the butterfly keyboard! So even thats not a blocker any more.

A very fast machine with only 16gb ram would be okay for me. But I do want an upgrade in that department.

I’d really be curious about your experience if you do decide to pull the trigger. I suspect that with integrated (everything), that Apple is doing some fancy tricks with swap files thus making 16GB good for larger workloads, but no review that I’ve seen yet has confirmed that.

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.

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 performance analysis because run time is a factor of IPC and clock speed. M1 has higher IPC because it runs at around 3 GHz compared to x86 CPUs running at 4 or 5 GHz. Apple optimizes for IPC, they are all different tradeoffs. Lastly, Apple's cores are probably the biggest in the industry. Compare their new generation of cores, they had to jumbo-size every structure (much larger than most x86 cores). So while it is impressive from a design point, from a micro-architecture point their cores have ballooned in size and are on 5 nm. Their architects are very good, but not godly like I see many tech sites ascribe them to be.

Experience: Designed SPARC, ARM, and x86 CPUs

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

I suspect that's largely due to the smaller process size.

To add to this: TSMC states either 15% performance or 30% efficiency gains on 5nm (relative to 7nm). Applying the 30% efficiency gains to the similarly performing Zen 3 CPUs gets you to similar consumption as the M1 (in a load scenario, big little has idle advantages).

The theory when the first Apple 5nm chip was announced is that Apple took the power efficiency gain.

>The one explanation and theory I have is that Apple might have finally pulled back on their excessive peak power draw at the maximum performance states of the CPUs and GPUs, and thus peak performance wouldn’t have seen such a large jump this generation, but favour more sustainable thermal figures.

Apple’s A12 and A13 chips were large performance upgrades both on the side of the CPU and GPU, however one criticism I had made of the company’s designs is that they both increased the power draw beyond what was usually sustainable in a mobile thermal envelope. This meant that while the designs had amazing peak performance figures, the chips were unable to sustain them for prolonged periods beyond 2-3 minutes. Keeping that in mind, the devices throttled to performance levels that were still ahead of the competition, leaving Apple in a leadership position in terms of efficiency.

https://www.anandtech.com/show/16088/apple-announces-5nm-a14...

Similar to overall performance, power consumption has many factors. As others have pointed out, a new process is a big part of it. Additionally, they have very efficient and well designed small cores in their SoC and one benefit their full vertical integration is their OS has very good schedulers for maximizing time on small power-efficient cores without impacting performance in a noticeable way. At a core level, I assume they have very good clock and power gating, so even if the cores have these massive structures, they might be able to power down some or all of them. For instance, adding a 4th vector unit might seem expensive, but most workloads are not running vector instructions, so all 4 of those units can be powered off for the time slice that application is running. Apple also has very good physical design teams that produce custom macros for almost the entire chip, which individually are very minor but do add up significantly.

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

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

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

Parent's comment was about micro-op caches. Modern x86 processors in a relatively tight loop do not decode the instructions each iteration.

I suspect you haven't internalized this, because reiterating the complexity of decoding instructions just isn't a valid response. The entire point is avoiding that cost.

An x86 instruction can decode into many more uops than an ARM instruction.

It could be more accurate to say the M1 can process twice as many half as complex instructions as x86.

For Intel cores "there are still five decoders in play. These decoders are split as one complex decoder and four simple decoders, and they can supply up to five micro-ops per cycle." vs. eight instructions per cycle for Firestorm. https://www.anandtech.com/show/14514/examining-intels-ice-la...

Most instructions are simple.

This is an oversimplified statement. Extra decode width only helps if the rest of the CPU can actually process so many instructions in parallel without blocking on other resources like memory. x86 CPUs also have their own features to alleviate the limited decode width such as micro-op caches.

Case in point is the Samsung Exynos M3, which despite its 6-wide decoder is barely competitive with the 3-wide ARM Cortex-A76. The Exynos would fare very poorly against any recent 4-wide Intel or AMD CPU.

The crazy thing about the M1 is that every structure in the CPU is huge - the decoders, the ROB, the number of execution units, even the caches. And apparently all of it is implemented very efficiently.

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

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.

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.

Yeah I really wanted to dig into AlitVec a bit more, but by the time I took a look at it, we had moved on to Intel. So I just tried to use the OS X vector libraries where possible, and hope for the best.

There was a paper that really got my attention, from US Air Force research I think, that reported a micro benchmark on a Mac Mini G4 where the AltiVec scores blew away their best Silicon Graphics beast.

The M1 reports feel a lot like that. Or better, because of the reports coming in on huge performance gains in real world apps.

Still way more slower than a Ryzen 4800 HS. Last time I checked a low end laptops with Ryzen had double performance (multi-core) compared to Macbooks with A1.

Can you be more specific as to what workloads you arecomparing? I find methodical comparisons quite scant. Anandtech has one page that includes the Ryzen 7 4800U and Ryzen 9 4900HS[0] for some synthetic integer/floating point benchmarks. In many cases the Apple Silicon M1 outperforms the Ryzen 7 4800U and in several it outperforms the Ryzen 9 4900HS. It's a bit difficult to extract from that how well they compete across all workloads, but it looks like they are quite comparable.

(And this is from someone who spends a lot of time trying to correct the misconception that the M1 outperforms all competitive processors.)

[0] https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...

Reply on news.ycombinator.com