Hacker News new | ask | show | jobs
by kryps 1865 days ago
It does not just feel faster, in many cases it is faster.

E.g. compiling Rust code is so much faster that it is not even funny. cargo install -f ripgrep takes 22 seconds on a Mac Book Air with M1, same on a hexacore 2020 Dell XPS 17 with 64GB RAM takes 34 seconds.

16 comments

I did a side-by-side comparing with my friends' M1 macbook and my (more expensive, nearly brand new) ryzen 5800x workstation compiling rust. The ryzen was faster - but it was really close. And the macbook beats my ryzen chip in single threaded performance. For reference, the ryzen compiles ripgrep in 19.7 seconds.

The comparison is way too close given the ryzen workstation guzzles power, and the macbook is cheaper, portable and lasts 22 hours on a single charge. If Apple can keep their momentum going year over year with CPU improvements, they'll be unstoppable. For now it looks like its not a question of if I'll get one, but when.

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.

> `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.
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 ;) ).
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
Did both machines compile to the same target architecture? If you did native compiles, then perhaps LLVM's ARM backend is simply faster than its x86 backend...
I think this is potentially a huge part of it - I'd do the benchmark by doing a native compile and a cross compile of each, and also do the same on a RAM disk instead of SSD (a large compile can end up just being a disk speed test if the CPU is waiting around for the disk to find files).
Maybe that would have been the case if only compilation times were reported to be good. But no, this is across many different kinds of workloads. Even Blender running in Rosetta can beat native x86 processors, which is bonkers.
I think these performance metrics are somewhat limited in their usefulness. A Ryzen workstation might not have the same single-core performance or energy efficiency—however, a ryzen workstation can have gobs of memory for massive data-intensive workloads for the same cost as a baseline M1 device.

In addition: let’s talk upgradability or repairability. Oh wait, Apple doesn’t play that game. You’ll get more mileage on the workstation hands-down.

The only win for those those chips I think is battery efficient for a laptop. But, then why not just VNC into a beastmode machine on a netbook and compile remotely? After all, that’s what CI/CD pipeline is for.

granted they charge exorbitant prices for their hardware, but I can’t believe how my 2010 MacBook Pro is still functioning perfectly fine.. except for them making it unsupported. I can’t say that about any other pc/laptop I have had. Not even desktops
I don't know, I feel other laptops at the same price point as Apple Macbooks do this too, sometimes even better. I bought a HP 8530w in 2009 or so and it still works. Replacing the DVD drive for a SSD required just a common Philips screwdriver and battery replacements are sold by HP themselves or many others.
Exactly. Too many people compare a $400 cheap Windows laptop to a $1200 Macbook. Compare like for like, and the thing is likely to last until it's absolutely obsolete. And, while I don't really support this, some might find it an advantage to replace the computer three times for the same price. But people should be comparing to a well built, upgradable laptop (especially those that support not just RAM and disk but also display upgrades and adequate ports), running an operating system that has no arbitrary end of life.
Lenovo or Dell displays are much worse than Apple displays even though the machine costs the same.
I’d love to see an actual serious comparison between an M1 Mac and a $400 laptop. That would be hilarious. Since there are so many of them, can you direct me to one, or even a few?
The point is that with mid-2010s apple laptops, >5 year lifespans are the norm. With the majority of other, even comparably priced laptops, that is the exception.

There are other laptops that are similar or superior build quality to those from Apple (N.B. - older MacBooks, not the newer ones) but those are also easy to spot. They’ll usually be ThinkPads or some XPS models from dell.

> With the majority of other, even comparably priced laptops, that is the exception.

Consumer grade PC hardware has terrible build quality, and regardless of the price of your unit, the consumer build spec is just inferior to the business/professional lines. Asus, MSI, Sony, Acer, etc laptops all have consumer grade build quality and they just aren't designed to last a decade.

> They’ll usually be ThinkPads or some XPS models from dell.

Precision/XPS and Thinkpad models (with the exception of the L and E series) are almost always in the same price range as a MacBook. Any business-class machine (Thinkpad, Precision/Latitude, Elitebook) should easily last >5 years. These are vendors which will sell you 3-5 year on-site warranties for their laptops.

This is why you can find so many off-lease corporate laptops on eBay from any model year in the last 10 years or so. The hardware doesn't break, it just becomes obsolete.

Oh that's baloney. There's nothing special about Apple laptops besides the metal case. Arguably they have worse cooling than most PC laptops. My 2018 MBP runs like it's trying cook an egg and has since day one. My Brother's 2012 MBP suffered complete logic board failure after 4 or 5 years.

If it wasn't for the replacement keyboard warranty offered by Apple a good chunk of butterfly keyboard Macs would be useless junk due to the fact it's so hard to replace them. Frayed MagSafe adapters were a regular occurrence. And swollen batteries pushing up the top case not that rare either.

I think maybe people keep MacBooks longer, but it probably has more to do with the fact they spent so much on them that they feel it's worthwhile to repair/pay for AppleCare than them actually being magically more durable.

Except that Apple considers these devices ’vintage' and will not provide OS updates or repairs.

https://support.apple.com/en-ca/HT201624

I was using my Dad's old ThinkPad 385XD from 1998 in 2009. Battery was unsurprisingly dead but every other piece was stock and worked although at some point I swapped the worn down trackpoint nub with one of the included spares we still had.
My "writing desk" PC is a Thinkpad X201 tablet from 2010, with the same SSD upgrade I put in my own 2010 Macbook Pro (a dedicated Logic Pro machine these days). There have always been manufacturers for whom that's the case on the PC side of things--you just kinda had to pay for it up front.
My two main PCs are a Phenom II-based desktop and a Thinkpad X220i (with the lowly Core i3, even!). Both are perfectly functional and usable today, with a few minor upgrades here and there, the usual SSDs, more RAM and a Radeon RX560 for the desktop.

The Thinkpad is obviously no powerhouse, but still works great for general desktop use, ie. browsing, email, document editing, music, video (1080p h264 is no problem). The desktop plays GTA V at around 40-50 FPS at 1080p with maximum settings. And this isn't some premium build, it's a pretty standard Asrock motherboard with Kingston ValueRAM and a Samsung SSD.

Decade-old hardware is still perfectly viable today.

I just had storage fail on my first gen touchbar macbook. It's a PITA, the storage is soldered onto a board. They replace the board, the can't recover the data (didn't expect them to). I'd pay the extra mm or two it would require them to just use a standard like m2. SSD storage just fails after awhile, especially if you do lots of things that thrash the disk.
Using 2011 sandybridge motherboard with a xeon-1230 i bought in 2012. I Had to replace 2 HDD + started using ssd for OS partition. It's working great, need to replace my nvidia GPU that is EOL but still working great.
I have an old gaming ASUS laptop from 2010. Still works like a charm after hard drive was switched to SSD. I have an even older Asus Netbook (15 years old eee PC I think) that still works. Netbook is too slow for modern software and I do not really use it but it works.
> But, then why not just VNC into a beastmode machine on a netbook and compile remotely? After all, that’s what CI/CD pipeline is for.

Is this how you work?

> Is this how you work?

This is exactly how I've worked for a number of years now, for my home/personal/freelance work. Usually using a Chromebook netbook ssh'ing into my high spec home server. I'd do the same for work, but work usually requires using a work laptop (MacBook).

I've worked that way for 10 years. My current desktop is a 5 year old Intel i3 NUC with a paltry 8G of memory. Granted, it uses all that memory (and a bit more) for a browser and slack, and the fan spins up any time a video plays. But usually it's silent, can drive a 4k monitor, and most of the time I'm just using mosh and a terminal, which require nearly nothing.

OTOH, the machine that I'm connecting to has 32c/64t, half a terabyte of RAM and dozens of TB of storage.

> the machine that I'm connecting to has 32c/64t, half a terabyte of RAM

Ok I'll bite, what do you do? Do you think halving the number of cores / RAM would impact your productivity?

A lot of what I do is compiling, so for that I'd still be fine with fewer cores and a lot less RAM. But I also do backtesting of trading strategies, and for that I can use all the cores I can get. The memory is needed to cache the massive amount of data that is being read from a pair of 2T NVME SSDs. Without adequate caching, I/O can easily become the bottleneck, even though the SSDs are pretty fast.
My work takes place at a beefy desktop machine. I wouldn't want it any other way... I get to plug in as many displays as I need, I get all the memory I need, I can add internal drives, there's no shortage of USB ports or expansion - and I get them cheap. For meetings or any kind of work away from my desk I'll remote in from one of my laptops.

All that and my preferred OS (Manjaro/XFCE), which runs on anything, has been more stable than any Mac I've ever owned. Every update to macOS has broken something or changed the UI drastically and in a way I have no control over...

If I ever switch away from desktops, it will be for a Framework laptop or something similar.

This is interesting - in the sense that you are someone who doesn’t want the UI to change, but it’s really not clear what this has to do with the question or the article.
I'm not the guy above, but I concur with the sentiments. After a while, adjusting to trivial UI changes becomes a huge chore and unnecessary cognitive overhead. It's relevant, because in order to use the M1, you have to buy into Apple's caprice.
Well, actually I have a beastmode mobile workstation that gets maybe 3 hours of battery life on high intensity. And when the battery is depleted I find a table with an outlet and I plug it in.

Everything in the machine can be upgraded/fixed so it should be good for a while.

I’m not saying this to be snarky. I just want to emphasize that while M1 is great innovation, I put repairability/maintainability and longevity on a higher pedestal than other things. I also highly value many things a computer has to offer: disk, memory, CPU, GPU, etc. I want to be able to interchange those pieces; and I want to have a lot of each category at my disposal. Given this, battery life is not as important as the potential functionality a given machine can provide.

Which 2021 laptop has replaceable CPU?
That's 90% how I've worked in ~15 years as an SWE.
> The only win for those those chips

I suspect the number of people, even developers, for whom 16GB memory is plenty probably greatly exceeds the number who need a beast mode Ryzen. But even then, a large proportion of the devs who might need a Build farm on the back end would be doing that anyway so they might as well have an M1 Mac laptop regardless.

Anyway Mac Pro models will come.

Power consumption is a good point. I wonder what the M1's power consumption is during those 19.7 seconds of compiling ripgrep compared to other platforms.
Low.

For me, SoC power draw when compiling apps is usually around 15 to 18W on a M1 mac mini.

My example app (deadbeef) compiles in about 60 seconds on that mac mini.

On a 2019 i7 16” MBP (six core), it takes about 90 seconds, and draws ~65W for that period.

So… radically more power efficient.

edit: this is the same version of macOS (big sur), xcode, and both building a universal app (intel and ARM).

I'm seeing a big different when compiling our project, with the M1 Macbook Pro beating the iMac Pro when building our projects (23min vs 38 mins).

Is it all CPU though, or is building ARM artefacts less resource intensive than bulding ones for Intel ?

iMac Pro has a large variety of performance, going from 8 to 18 cores and it uses a 4+ year old Xeon CPU. Unsurprisingly the 18 core handily beats the M1 in multi-core benchmarks:

18 core iMac Pro 13339: https://browser.geekbench.com/macs/imac-pro-late-2017-intel-...

M1 Mac mini 7408: https://browser.geekbench.com/macs/mac-mini-late-2020

>For now it looks like its not a question of if I'll get one, but when.

My exact sentiments. I've been looking for a gateway into Apple and the M1 Air seems like it. It has now become a matter of time and not just a fleeting thought.

> If Apple can keep their momentum going year over year with CPU improvements

I’ve been blown away with games running on M1. If Apple could up their GPU game as well, that’d be really cool.

Are you sure Rust compilation can use multiple cores to the fullest?

I don't use Rust, but a quick search returned for example this issue:

https://github.com/rust-lang/rust/issues/64913

My cpu usage graph shows all cores at 100% for most of the compilation. But near the end it uses fewer and fewer cores. Then linking is a single core affair. It seems like a reasonable all-round benchmark because it leans on both single- and multi- core performance.

And I really care about rust compile times because I spend a lot of small moments waiting for the compiler to run.

How long is the battery life on both if compiling non-stop? Assuming both keep similar compile from start of battery to end it would be interesting to see if the ryzen is truly guzzling batteries.
I'm guessing the 5800x work station is a desktop, not battery powered...
You are right. Missed then when i was angerly responding.
I have a Ryzen 7 4700g. I wanted to compare this to the GPU side of the M1. On Geekbench OpenGL test, it was slightly faster than the M1. I would like to find a better test.
> macbook … and lasts 22 hours on a single charge

I keep hearing this but have not experienced this in person. I usually get about 5 hours of life out of it. My usual open programs are CLion, WebStorm, Firefox (and Little Snitch running in the background).

However, even with not having IDEs open all the time, and switching over from Firefox to Safari, I’m only seeing about 8 hours of battery life (which is still nice compared with my 2013 MBP that has about 30 minutes of battery life).

>However, even with not having IDEs open all the time, and switching over from Firefox to Safari, I’m only seeing about 8 hours of battery life (which is still nice compared with my 2013 MBP that has about 30 minutes of battery life).

I would consider getting a warranty replacement. Something is wrong.

For reference, my M1 Air averages exactly 12 hours of screen-on time (yes, I've been keeping track), and the absolute worst battery life I've experienced is 8.5 hours, when I was doing some more intense dev workflows.

The Macbook Air does not get 22 hours but the Macbook Pro gets kinda close under the conditions specified in the test.
I'm still unconvinced it's the M1's design and not TSMC's fab process.
When you move to a smaller process node, you have a choice between improving performance or cutting power. (or some mix of both)

Apple seems to have taken the power reduction with the A14 and M1 on TSMC 5nm, not the performance increase.

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

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

I think the latest Ryzen 5800x CPUs kind of prove it's the TSMC fab process. You've now got M1s, Graviton2s, and Ryzens all crushing it to similar levels.
I dunnoh... the Ryzen 5800x laptops seem to be able to stay ahead of the M1's for most tasks.
Huh? 5800x laptop? The 5800x is a desktop chip.
The 'X' was meant to be "various letter extensions on the 5800 series", such as 5800U, 5800H, 5800HS. I probably should have used different terminology from the model number, as there are other Zen 3 mobile processors like the 5900HX, 5980HS and 5980HX that if anything make the point stronger.
After buying my M1 and benchmarking it against the top of the line i9 I considered shorting Intel's stock, alas they're so large it'll take a while for the decline to catch up with them.
In previous discussions about this it was pointed out that LLVM may be significantly faster at producing ARM code versus x86. The comparison may still be the one that actually matters to you but at least in part be an advantage of ARM in general and not just the M1. rust is very good at cross-compiling so compiling to ARM on Dell and to x86 on the M1 may add some interesting comparisons.
So then the next question is, is this really an apples-to-apples comparison? It wouldn't surprise me at all if the x86 back-end takes more time to run because it implements more optimizations.
Are you compiling for ARM in both cases (or x86 in both cases)? Otherwise you are building 2 completely different programs, one is ripgrep for ARM and the other is ripgrep for Intel.
The programs would be pretty much identical until they are lowered, which is generally not a bottleneck for Rust compiles…
In native Typescript compile of a very large angular app I see an even more dramatic 1:20s to 40s compared to a desktop i9. I feel as if the M1 may have been designed around a detailed and careful look at how computers and compliers work and then designed a CPU around that rather than the other way around.

It's like buying a car and modifying to take it racing vs buying a race car, the race car was designed to do this.

>> I feel as if the M1 may have been designed around a detailed and careful look at how computers and compliers work and then designed a CPU around that rather than the other way around.

This is the position that Apple have set up for themselves with their philosophy and process. It would seem that Intel and AMD have to play a very conservative game with compatibility and building a product that increments support for x86 and x64. They can't make some sweeping change because they have to think about Linux and Windows.

Apple own their ecosystem and can move everything at once (to a large degree.) This also gives an opportunity to design how the components should interact. Incompatibility won't be heavily penalized unless really important apps get left behind. The improvements also incentivize app makers to be there since their developer experience will improve.

> It would seem that Intel and AMD have to play a very conservative game with compatibility and building a product that increments support for x86 and x64.

Talk to people who design chips. The compatibility barely impacts the chip transistor budget these days, and since the underlying CPU isn't running x86 or x64 instructions, it really doesn't impact the CPU design. There may be some intrinsic overhead coming from limitations of the ISA itself, but even there they keep adding new instructions for specialized operations when opportunities allow.

Exactly this. Apple has spent decades drilling a message into third-party developers: Update your apps regularly or get left behind.

Everyone who develops for one of their platforms is just used to running that treadmill. An ARM transition is just another thing to update your apps for.

App developers are incentivized in another way: software that takes advantage of new features or performance are often what Apple chooses to promote in a keynote or in an App Store’s featured section.
Typescript compilation doesn't use all the cores available on the CPU; I think it maxes out at 4 as of now [1]. This might be working well for M1, which has 4 high performance cores and 4 efficiency cores.

[1]: https://github.com/microsoft/TypeScript/issues/30235

What OS are you running on the Dell though? Windows is notoriously slower for file system operations even without AV and the default there is to prefer foreground apps vs something like compile tasks.
Yep, see below. With WSL and an ext4 virtual disk it takes only 29 seconds. Still quite a bit more than the 22 seconds on the Macbook.
WSL2 right? Given the virtualization overhead for IO I would expect native Linux to be faster.
WSL2, correct.
Hard to compare without mentioning the actual CPU in it. FWIW my Ryzen 3900X completes that compile in 15s.

To be fair, that is a relatively high-end desktop CPU, but it's also a massive margin for a last-gen model.

We also have to consider the i7 and M1 run at about 1/7 the TDP of the Ryzen. Just underscores the good design behind the QoS and judicious use of the Performance cores vs Efficiency cores.
Yeah, but that's previous generation. Get a 5850U or even a 5980HX...
My water-cooled 3900XT is locked to 4.4ghz all cores with relatively fast double banked 2x16GB c15 3600mhz memory. (It never drops under 4.4 on any of the 12/24 cores.)

Also has a Samsung 980 1TB drive, and a 3070 GPU; the system truly is extremely quick. (Win10+WSL2).

(I'll have to try that compile in the next day or so; will reply to myself here).

OS matters for this comparison. If your Dell XPS was running Windows, that might explain the discrepancy.

For instance Windows on NTFS etc. is notoriously slow at operations that involve a lot of small files compared to Linux or whatever on ext4.

Unless your Dell was also running OSX, you're probably not comparing hardware here.

For me, it takes 34 seconds on M1 (MBP13):

    Finished release [optimized + debuginfo] target(s) in 34.50s
    ...
    cargo install -f ripgrep  137,66s user 13,00s system 435% cpu 34,632 total
For comparison TR1900x (yeah, desktop, power-guzzler, but also several years old), Fedora 34:

    Finished release [optimized + debuginfo] target(s) in 25.15s
    ...
    real        0m25,271s
    user        4m41,553s
    sys         0m7,216s
Thank you for the perspective.

Here's r7 4800HS (35w) on linux:

Finished release [optimized + debuginfo] target(s) in 24.98s

real 0m25.151s

user 4m54.987s

sys 0m6.764s

I just did a test on my old Lenovo laptop... Intel i7-8565U CPU @ 1.80GHz

# git clone https://github.com/BurntSushi/ripgrep && cd ripgrep

# cargo clean

# time cargo build

real 0m23,805s

user 1m11,260s

sys 0m3,806s

How is my crappy laptop on par with your M1? :)

You are not doing a release build.
thanks, problem solved - now it's 1 minute...
Wow. The fact that my Sandy Bridge laptop from 2011 does it in only 1:41 is pretty indicative of how badly processor improvements stalled out last decade. My processor (like yours, 4c8t): https://ark.intel.com/content/www/us/en/ark/products/52219/i...
You compare TDP 45W CPU vs 15W. I think this is great improvement. (But latter one is also 25W cTDP and turbo boost provides more power, many factors depends on how the laptop implemented)
I think the point is even a laptop from 2011 is acceptable for development. I wouldn't mind the power draw since its plugged in, the compile time either, cold compile 20s-2min is much the same for me, recompile where it counts is much faster
Are you counting download time as well? It took 8.30 sec on hexacore now when I tried it.
Nope, pure compile time on a Core i7-10750H with Windows and Rust 1.52.1, antivirus disabled. WSL did not make much of a difference though (29 seconds).
The Windows filesystem is extremely slow, even without WSL. It can be mitigated to some extent by using completion ports, but I doubt the Rust compiler is architectured that way--

You should benchmark against Linux as well.

cargo install on WSL2 uses the non-mapped home directory, which is on an ext4 virtual disk. That is probably one reason why it is six seconds faster.
> Windows

There's your problem.

Even Microsoft concedes that Windows is legacy technology now.

You must be joking? If not, provide us with a source
And here I thought that having a desktop CPU like Ryzen 5 2400G with loads of RAM would take me somewhere. It took the machine around 71 seconds.

EDIT: could you measure C compilation. For example:

  git clone --depth 1 --branch v5.12.4 "git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
  cd linux
  make defconfig
  time make -j$(getconf _NPROCESSORS_ONLN)
For me it's slightly below 5 minutes.
It took the machine around 71 seconds.

Are you including download time? On my Ryzen 7 3700X, it's done in 17 seconds.

Specifically I did it two times to not see the download/syncing time. Also to a fresh home. 3700X has 16 threads, 2400G has 8, that probably makes up for the most of the difference. But M1 has 8 cores (4× high-performance + 4× high-efficiency. Maybe rust version also counts? I'm on rust 1.48.

EDIT: I checked on 1.52.1, which is latest stable and it went down to 54 seconds. So that also makes up a significant difference.

It's been amazing for me.... EXCEPT for when resuming from sleep, for some reason it would be very slow for a minute.

I have since FIXED THIS! The solution is to just not let it sleep. I'm using Amphetamine and since then it has been amazingly fast all the time.

> I'm using Amphetamine and since then it has been amazingly fast all the time.

I think these app makers might need to start focus grouping some of these app names. Not only is it going to be harder to search for this app, but it'll inevitably also lead to some humorous misunderstandings.

They already got pulled from the App Store (although Apple reversed course after significant badgering): https://news.ycombinator.com/item?id=25605880
Is 22 seconds insetad of 34 seconds so much faster ? The difference does not feel huge to me
yes, it compiled the project in 35% less time. doesn't really matter much for such a small project, but imagine if on a larger project the intel part took an hour and the m1 did it in 39 minutes. that's a substantial speedup. of course, we might see different results after leaving the turbo window.
You're assuming that the scaling is linear though. What if there's a fixed 10 second ding on x86? That 39 minute compile on the m1 would only be 39:10 on the x86.
> What if there's a fixed 10 second ding on x86?

There isn't.

And yet it is extremely unlikely that it's linear or anywhere near it.
What is "linear" in this context? If the Y-axis is performance, what is the X-axis? That statement doesn't seem to make much sense without any additional explanation.

If I run a benchmark for a program on the M1, that's a single data point. It's hard to call a single data point "linear", "quadratic", or anything else... and you can't really put multiple benchmarks on the X-axis, because they're measuring different things.

What would even make it (whatever "it" is) "extremely unlikely"? People have had over 6 months to run benchmarks on the M1. Surely you can find a concrete answer to your question that doesn't involve random speculation on internet forums?

Based on my own experiences, I have no reason to believe that the M1's performance starts tanking if you run it for longer than a few seconds, in case you're implying that the other processors will "catch up" if they have longer to get up to speed... why would they? That makes no sense either. Longer compilations are faster on M1 too, relative to my Intel hexacore MBP, from what I've seen in the past. I mean, obviously, right? Why wouldn't they be? Intel's processors change frequencies in milliseconds... it doesn't take them minutes to warm up.

The M1 isn't a silver bullet. AMD makes laptop processors that are more powerful. But the M1 is still really good for what it is, and those AMD processors consume notably more power than the M1 to achieve their performance.

I'd gladly spend 14 seconds if it helps me avoid Apple products!
How long does it take on a Ryzen 9 5950X
Note that's a 16 core CPU with 105W TDP compared to a quad core < 10W M1
5850U is an 8 core CPU with a TDP that is adjustable between 10-25w. If you want to keep it to 4 cores just so it is a fair fight, there's the 5400U/5450U. AMD does pretty well...
Yeah I'd say the M1 and latest AMD CPUs are virtually tied for fastest single threaded performance, edging out the best by Intel.

But for something like compilation which is multithreaded obviously the higher core count will win.

Yup, and the new macbook pro will probably be twice as fast
Source?
Gut feeling ;-)
Ran a few cycles on my 5950x hackintosh:

  invaderfizz@FIZZ-5950X:~$ hyperfine 'cargo -q install -f ripgrep'
  Benchmark #1: cargo -q install -f ripgrep
    Time (mean ± σ):     19.190 s ±  0.392 s    [User: 294.890 s, System: 17.144 s]
    Range (min … max):   18.352 s … 19.803 s    10 runs
The CPU was averaging about 50% load, the dependencies go really fast when they can all parallel compile, but then the larger portions are stuck with single-thread performance.
My 5950X came in faster running in WSL2, but then I do have a Samsung 980 PRO running in a PCIe 4.0 slot.

  Benchmark #1: cargo -q install -f ripgrep
    Time (mean ± σ):     11.585 s ±  0.474 s    [User: 176.733 s, System: 5.677 s]
    Range (min … max):   11.271 s … 12.867 s    10 runs
Which I suspect leans towards an IO bottleneck.
Just for reference (5950x too): ran 3 times just measuring with `time` on void linux using cargo from xbps. Mean of the last two runs (first was syncing and downloading) was ~13.8 s.
Okay, compiling is faster. But you compile once and run many times. What about running it?