The Only M1 Benchmark That Matters | Hacker News Reader

The Only M1 Benchmark That Matters

lars.ingebrigtsen.no

97 pointsnemoniac51 comments

Just as a quick comment—the difference in compile times between Clang and GCC is fairly significant. I regularly see much shorter compile times on macOS development systems and after trying Clang on Linux, the gap narrows significantly.

My most recent experience was with building GCC for cross-compiling. I had been doing work on Linux and spun up a cloud VM instance to do the compiling there with tons of CPU. Later, I wanted a Mac build environment set up, and when I compiled GCC on macOS with Clang, it was much faster to build. I went back to my Linux system and tried compiling GCC using Clang there, and got the same result.

Clang is fast. Just saying.

Phoronix currently have GCC faster than Clang at compiling the Linux kernel.

There was a big thread on it recently

Sure… it does depend on the code base. My experience was with GCC 10.2 (both as code base and as compiler).

At the same time, the Linux kernel uses so many GCC specific extensions to C that an unpatched Clang couldn't even compile it until 2019. It is not in any way a typical program.

But he does the same build on his 2019 Mac laptop, which presumably also uses Clang. The M1 blows it away.

The benchmark that matters to me is battery life. I read that you can get a full day out of these things if you work them hard and 2 days if you're not so demanding.

The fact that you get this sort of battery life with high end desktop performance is incredible.

Only if you can successfully avoid rosetta 2. The battery life shrinks considerably otherwise.

Most of what I do on my Mac is using Rosetta (developer) and I can easily get an actual 12+ hours out of my MacBook Air compared to around 4 hours from my 16” MacBook Pro. It’s just as fast (or faster). It’s astonishing.

That's true. I can easily get more than a day's worth of work (coding + reading + browsing for reference) out of the M1 without having to reach for my charger. Of course I mostly use vim for coding, so YMMV if you're using something heavier like VSCode, Intellij, etc.

It's very true. I bought an M1 laptop a few weeks ago, and I'm near Seattle right now in the middle of a long power outage with no end in site, and suddenly the amazing battery life of this laptop is even more valuable.

I have daily power outages and I'm lowkey considering breaking my self-imposed rule of never buying first generation tech for the M1.

I can't wait to not have to leave my laptop plugged in all the time.

Not for me

It's something like 4 hours.. probably bc of chrome. I dunno.

I agree, and it matters to non power users aswell, in general a new standard of quiet, cool, long lasting computing that is unmatched by anything else on the market.

If I go and buy an Apple M1 (speaking as a Linux guy who never owned a Mac...), will you guys promise to stop posting benchmarks here? Pinky promise?

Yes, but first you need to post your own benchmark

PS: That benchmark is impressive!

LOL it's a deal!

No, the M1X is coming soon

This is the second time I've seen compilation as a benchmark since the M1 came out.

If you are not building for the same target (ie both building for arm or x86) using the same version of the compiler, it doesn't count. This is like opening libre office writer on one computer and MS word on another and calling the startup time a benchmark.

I dunno. If I can build for a target 5x faster than another target, do I care that I'm using a different compiler or do I want 5x faster compiles?

If you have binary libraries that only work with one compiler then you certainly do.

My _anecdotal_ understanding is that _generally_ on _average_ for identical as they can be targets, gcc compiles faster but generates slightly larger artifacts while clang would compile slower but generate slightly smaller artifacts.

This makes me wonder if a comparison not using the same compiler really reveals enough of the story here.

I did something similar for emacs here:

https://twitter.com/hagmonk/status/1338965551775764481

and got similar looking improvements. I also benchmarked Leiningen startup times:

https://gist.github.com/hagmonk/ee5eaa8c07e245422ec384737cb4...

Basically, it's not uncommon to find things running 1.5x faster on M1. Even outside of benchmarks, everything is perceptibly - dare I say it - snappier.

Interesting results re: emacs. Your tweet says you’re using emacs-plus, presumably via brew? Are you running emacs with Rosetta or is it an arm64 build?

Has anyone properly benchmarked virtualized Linux? I'd be very interested in those compile times (let's try the Linux kernel as a standard benchmark).

You can't compare the performance of an SoC with a flexible architecture in which any part can be changed, upgraded, etc. It's impressive, of course - no doubt, but this is not apples-to-apples comparison. The performance is due to huge compromises. It will be costly to repair, too, given EU is mandating the right to repair now. Anyway, competition is great and Intel and AMD are already taking notes.

That's what I think too and I get downvoted all the time for saying that a system on a chip freshly designed from the ground up with mobile use as a goal, with tightly integrated everything and ad-hoc software written on top of course runs great.

Now I have to wonder why no other vendor (who are all moving in the direction of SoC, including Intel and AMD AFAIK) thought of that.

Qualcomm did, but their performance in the surface products from Microsoft is nowhere near this performance.

repair process will probably be:

"here's a new, have a nice day"

Agree. With traditional PCs, just length of these DDR4 wires in the motherboard adds like 4-7 CPU cycles of main memory latency.

Of course you can. In fact, the user included a not- particularly upgradable or reparable Intel Macbook in the comparison.

Compile times and upgradeability/reparability are not mutually exclusive.

It is not wrong to highlight the tradeoff. But people are allowed to decide "I want to give up reparability for nearly 5x faster compiles." Which is what the person got when comparing to the prior generation Macbook with the same compiler.

How is the driver support for M1 (scanners, printers, etc)? I don't use macos, but I have some family members who are due for an upgrade.

I haven’t had to install a printer driver to print from macOS in ages. Unless you’ve got a weird/old printer, it’ll probably just work with AirPrint out of the box.

I see, yes most default printer drivers do work, but I believe you still need software for scanners, and probably (atleast this is true on Windows) some printers allow advanced changes to settings only via their software.

My M1 Air prints to my Brother printer that’s connected to WiFi. I didn’t install anything on my M1.

"The old Apple laptop would sound like a VAX in a hurricane while building Emacs!"

Sysadmin to a VAX farm in an earlier life -- this brought back some good memories, especially of what our server room sounded like when we pushed a new build... Thanks for that.

This was charming.

Also, I like compile-time benchmarks. They are meaningful to me.

Sidebar: I want to love the TrackPoint but I almost always hold stress in my neck as I use one. Am I alone?

Pointless nitpick: replace

    rm `find lisp -name '*.elc'`

with

    find lisp -name '*.elc' -exec rm {} \;

So long as we're nitpicking...

The version you're replacing is two processes. It may, with enough files, give an error about a command line length limit. However, it's one find and one rm. Your version spawns rm for every file found, basically like using xargs.

If you want the best of both worlds, try:

    find lisp -name '*.elc' -delete

Thanks, TIL! I really should read the `find` man page more carefully one of these days.

(The original version will also fail to remove files with names containing spaces.)

That's true. Getting shell escapes right for various shells is not a fun thing to do, either. I think the ship has sailed on convincing people not to use spaces in file names, so that's always good to check.

I'll probable wait for higher end systems.

I would love to see a benchmark like this that actually controls for GCC vs. Clang and Linux vs. XNU.

and storage speed, and file system, and the different executable formats and machine architectures...

Clickbait title.

Reply on news.ycombinator.com