Go standard library benchmarks – Intel vs. M1 | Hacker News Reader

Go standard library benchmarks – Intel vs. M1

roland.zone

58 pointsjeremylevy33 comments

This compares a 2020 M1 13" Macbook Pro with a 2017 13" Intel Macbook Pro. The 2020 machine is faster and that is great, but its also 3 years newer.

Is this more or less than the expected improvement in benchmarks if this were an Ice Lake or Ryzen 4000 CPU in an equivalent form factor? Are there similar benchmarks comparing e.g. a 2020 Dell XPS 13 to an M1 Macbook Pro?

It's also i5 on top of that. Kinda random choice of comparison hardware IMHO. "I had this thing lying around so I tested my new daily driver against it". I can definitely see the appeal of doing that for yourself, but it's also quite misleading.

So it basically excels at everything but cryptography where it's terrible in comparison. I found this a little interesting because it should have custom hardware specifically for this (i.e. an AES engine which is what's being benchmarked here), formerly in the separate Apple T2 security chip? I wonder if this test simply doesn't use that hardware (lack of support in Go libs?) or that it does but it really is this much worse. (or a third option -- there is support but the T2 doesn't accelerate many of the features tested and it's more special purpose for only specific calls from macOS)

It explains why at the second paragraph.

> A top level takeaway from this data is that for things that rely on pure Go the M1 machine is, in general, a good bit faster than the Intel machine. For code that relies on highly optimized assembly, like a good chunk of the crypto/ code, the Intel machine wins (although I wouldn’t be surprised to see significant gains for the M1 as arm64 assembly implementations get more attention and are further polished).

Basically Go lacks lots of optimized assembly code for ARM64.

There does appear to be ARM64 assembly in Go's crypto code, but perhaps it's suboptimal for M1. Or perhaps there's a build config issue, and the assembly isn't being used. Just my speculation, though. I haven't looked into it.

https://github.com/golang/go/blob/master/src/crypto/aes/asm_...

As the article says, the crypto on x86 is hand-optimized assembly, whereas the M1 is running the fallback C.

In other benchmarks like geekbench, which are not benchmarking golang's libs, the M1 is massively stronger than Intel on e.g. AES-XTS.

https://www.extremetech.com/computing/317304-benchmark-resul...

So hopefully the M1 gets the same hand-optimizing effort that x86 historically got.

I think it’s just testing whether the backend is assembly or not; pure Go impls are faster, for example:

https://twitter.com/FiloSottile/status/1328886085318021120

x86 has AES implemented as native instructions (AES-NI). ARM devices normally add a crypto accelerator chip if they need it. Apple's T2 secure enclave provides exactly this.

Go libs just need to be tweaked to use the correct chip to do the work.

Looks like they did do AES-XTS on the main die because it is required for encrypted storage.

Exciting times for CPU architectures this year with both the M1 and Zen 3 being highly competitive. The 2010s were a bit of a stagnation when it comes to performances, lets hope more the 2020s is more interesting.

Does anyone know why this was? For an outsider, it seems like something went seriously wrong at Intel: the exploits, plus not making serious advances, and now seeing what M1 can do on laptop processors.

Complacency?

There was no competition for Intel in the x86 market. They attempted to enter mobile which was a huge and growing market and they failed.

This stagnation may have fuelled development elsewhere (RISC-V?) and now that AMD is "back in the game" and ARM is making its way into server hardware and "desktop", there's real competition again.

Not directly involved, but repeating what I've heard from others here: Intel apparently got taken over by MBA-types who didn't understand what it takes to generate long-term engineering value (a bit like Boeing?). It also refused to pay competitive salaries even when it was rolling in cash, making it easy for competitors to poach its talent.

(Boeing brought McDonnell Douglas in 1997, but management-wise, MD's beancounting culture took over Boeing's engineering culture. A kind of reverse-merger. Several pundits lamented this in the wake of the 737-max scandal)

That was a market without competition. Without anything lighting a fire under Intel they had no reason to improve the chips further and kept making tiniest of iterative improvements year after year.

I wonder if there's a price Intel, and AMD, is forced to pay, in terms of dealing with 40 years of x86 legacy, which limits performance in some way.

A long time ago, when RISC was first posited, we all thought that RISC vs CISC was a big deal.

But these days, not really. Peel back and peer at the CPU and they all look and work much the same. The CISC implementations typically convert to their own simplified instruction subset internally, and the RISC crowd keep adding fatter and fatter CISC-like instructions.

So its not really an x86 instruction set problem. The legacy that Intel (and, a lesser extent, AMD) seem to struggle to overhaul is in their architecture, not the instruction set itself.

This is proven by the M1 doing binary translation of x86 and still being faster than the Intel chips.

> This is proven by the M1 doing binary translation of x86 and still being faster than the Intel chips

That’s the real kick in the nuts for intel isn’t it. I bet apple could have jumped last year or before and been ahead in native performance. But waiting meant they even beat intel at their own game, while massively handicapped.

Maybe not 2010, but some time before that it was evident that their architecture couldn't scale. They increased clock rate every year, and hit a wall. My Pentium 4 in 2006 or so still had much more GHz than any CPU I've had since. After hitting the ceiling, they pushed on in that direction for far too long before rethinking the approach, like getting blood from a stone.

I think this Steve Jobs clip explains it pretty well.

https://youtu.be/K1WrHH-WtaA

Basically Intel didn’t need to innovate to make money the last decade. Now it’s come to back bite them on the ass.

If M1 is indeed this good at most tasks, it would be amazing if Apple were to release server grade Apple Silicon CPUs....

Imagine if we were able to run Linux kernel on such CPUs that didn't care about putting in the low power cores or GPU cores and optimised even more for performance. One can only dream so wild.

Some HPC shops would build racks and racks of those.

AWS released ARM instances in 2018. It is already happening in the datacenter.

Not an expert in HPC, but I think you gain the performance from distributing the data across a vast number of cpu instead of having great cpus to begin with.

There exists ARM CPUs designed for server workloads, but the design and trade-offs are really different than the ones you make when designing a laptop CPU, it would have little in common with the M1.

Also, these results are OK, because it means new macbook performance won't be diminished because of the switch to ARM, but it's not that much of a perf improvement either: keep in mind this benchmark was run against a 2017 i5 CPU. It's not an anemic CPU, but it's not really hard to beat either.

>but it's not that much of a perf improvement either: keep in mind this benchmark was run against a 2017 i5 CPU

We've seen 50% to 200% improvements over the latest i9 CPUs too...

I haven't seen those do you have a link? Anyway, given the results in the benchmarks we're talking about, I'd be surprised if an M1 scored ahead of a current Ryzen on these.

If M1 is indeed this good at most tasks, it would be amazing if Apple were to release server grade Apple Silicon CPUs....

This is not going to happen, Apple exited that business in 2010 and have shown no signs of rekindling that interest. I agree with you that there could be a lot of potential in Apple Silicon in 1U rackmounts but I am not holding my breath. Apple is 100% focused on consumers, it is not interested at all in datacentres, it doesn't even run OSX in its own datacentres.

Misleading not sure why this is on the front page. That's a 2017 i5 Kaby Lake CPU. Either make a through review, or comapre against the latest not just a random old CPU

I'm guessing its just a placeholder for today's "excited about the M1" discussion?

M1 is the most exciting thing to happen in tech this week. Or at least I think so :)

>Misleading not sure why this is on the front page

Because it was upvoted. Same as most things that go into the front page, aside from YC promos.

So, I read correctly, these are microbenchmarks, ran 5 times each (it's not specified)? Also anyone notice the extreme performance difference for non-CPU-bound things (like: DNS-lookup).

I'm still unconvinced and wait for some good old BLAS...

me too.

answering to myself: https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste... that's SPEC at least and most interesting, now the non-Mobile A14 is not beating the old guard x86 y magnitudes (which you saw people telling below the A13 article on the same site and respective HN-posts). It's certainly superfast in singlecore, but it's telling that multicore is benchmarked vs. mobile processors (and not vs. the normal Ryzens/Intels which you can expect in a corded setup nowadays!).

As for the linked microbenchmarks: I guess with 12MB of cache, there's plenty of memory to place the kernel and some other stuff. I wonder, how this plays out here.

Nice job.

A better way might have been to run the Go1 benchmarks instead. That contains a pre-selected set of benchmarks that tests a variety of workloads.

benchmarked against Core i5-7267U released 3th of January 2017, 4 years ago.

Reply on news.ycombinator.com