Hacker News new | ask | show | jobs
by omegabravo 1865 days ago
I've done a side by side with my Ryzen 3700x compiling a Go project.

6 seconds on the Ryzen, vs 9 seconds on the M1 air.

`time go build -a`, so not very scientific. Could be attributed to the multicore performance of the Ryzen.

Starting applications on the M1 seems to have significant delays too, but I'm not sure if that's a Mac OSX thing. Overall it's very impressive, I just don't see the same lunch eating performance as everyone else.

The battery life and lack of fans is wonderful.

edit: Updated with the arm build on OSX. 16s -> 9 seconds.

5 comments

> `time go build -a`, so not very scientific.

A tool I have enjoyed using to make these measurements more accurate is hyperfine[0].

In general, the 3700X beating the M1 should be the expected result... it has double the number of high performance cores, several times as much TDP, and access to way more RAM and faster SSDs.

The fact that the M1 is able to be neck and neck with the 3700X is impressive, and the M1 definitely can achieve some unlikely victories. It'll be interesting to see what happens with the M1X (or M2, whatever they label it).

[0]: https://github.com/sharkdp/hyperfine

M1 S Pro Max
Faster SSDs on the Ryzen machine? The SSD on even my 2019 Macbook pro is ridic
I find M1 optimized apps load quickly while others vary. But what really varies is website load times. Sometimes instant, sometimes delayed.

All this said, there really is no comparison. I don’t even think about battery for the M1, I leave the charger at home, and it’s 100% cool and silent. It’s a giant leap for portable creative computing.

> Starting applications on the M1 seems to have significant delays too, but I'm not sure if that's a Mac OSX thing.

That's a Mac OSX thing. It's verifying the apps.

https://appletoolbox.com/why-is-macos-catalina-verifying-app...

If it's Intel-compiled apps, it's also that Rosetta is translating them to run on M1 when they're first run, as I understand it.

Both of these are first-time launch issues, so comparing launch times on the second launch is probably more reasonable.

Good point. I'm really surprised they don't translate during installation (ahead of time).
I believe they do.
In certain cases, such as when they come from the App Store. I believe other apps do not get this.
I think Installer.app triggers the AOT translation, too?
I’d like to point out that compiling stuff is usually disk/io intensive. Could this not just be that the Apple machine has a faster hard drive/memory?
It doesn't. It has the same 4 lanes, PCIe 3.0 flash as everyone else.
They have an extremely heavily integrated flash controller. Part of it is what they bought from Annobit.
I know, but the flash controller isn't the slow part (usually ;) ).
It does for real world tasks, rather than benchmarks. The FTL plays a big part in real world, small access latency.
We still don't know how good is the FTL in the Apple controller; all the devices are still too new and haven't been dragged through the coal as all the other controllers. It is still in the "easy job" part of it's lifecycle, with brand new flash cells.

However, to quote @Dylan16807 from similar discussion few weeks ago (https://news.ycombinator.com/item?id=26118415):

> The analog parts are the slow parts.

PCIe 4.0 is the current standard.
update:

time GOARCH=amd GOOS=linux go build -a

6s for the M1 too!

Do keep in mind that go heavily caches for "go build":

https://golang.org/cmd/go/#hdr-Build_and_test_caching

the "-a" directive in "go build -a" should cause a clean rebuild, which is what they were using