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.
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.
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.
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.
However, to quote @Dylan16807 from similar discussion few weeks ago (https://news.ycombinator.com/item?id=26118415):
> The analog parts are the slow parts.
And the Annobit IP includes the analog parts as a large piece of their value add.
In practice, the I/O performance of M1-based Macs is comparable to random PCIE 3.0 NVMe drive. (I'm typing this comment on M1 MBP, I'm well aware how it performs).
That's a Mac OSX thing. It's verifying the apps.
https://appletoolbox.com/why-is-macos-catalina-verifying-app...
Both of these are first-time launch issues, so comparing launch times on the second launch is probably more reasonable.
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).
time GOARCH=amd GOOS=linux go build -a
6s for the M1 too!
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.
No good way to check for it, because no LEDs on the outside. Only way to check is to see if the fans switched on after five minutes in the bag.
You are better of with a business or workstation laptop.
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.
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.
(I do hear that their business support is pretty good though)
~8 years ago; within 48h of the laptop breaking - had a Dell repair tech sitting at my kitchen table replacing mainboard on an XPS laptop. Has turnaround when you have the proper support contracts gotten that much worse?
(admittedly, we did pay for the top support tier for a personal device as it was expensed for work. I wouldn't do anything else from any manufacturer though unless I had on-site tech support/replacement.)
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.
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.
Is this how you work?
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.
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.
I think it’s valid to want not to have to deal with the cognitive overhead of UI evolution.
It’s equally valid not to want to deal with the cognitive overhead of various attributes of Linux.
What’s not obvious is why people sneer about it.
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).
OTOH, the machine that I'm connecting to has 32c/64t, half a terabyte of RAM and dozens of TB of storage.
Ok I'll bite, what do you do? Do you think halving the number of cores / RAM would impact your productivity?
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.
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...
Is it all CPU though, or is building ARM artefacts less resource intensive than bulding ones for Intel ?
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
I don't use Rust, but a quick search returned for example this issue:
And I really care about rust compile times because I spend a lot of small moments waiting for the compiler to run.
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).
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.
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.
I’ve been blown away with games running on M1. If Apple could up their GPU game as well, that’d be really cool.
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).
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.
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.
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.
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.
To be fair, that is a relatively high-end desktop CPU, but it's also a massive margin for a last-gen model.
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).
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.
Finished release [optimized + debuginfo] target(s) in 34.50s
...
cargo install -f ripgrep 137,66s user 13,00s system 435% cpu 34,632 total
Finished release [optimized + debuginfo] target(s) in 25.15s
...
real 0m25,271s
user 4m41,553s
sys 0m7,216sHere's r7 4800HS (35w) on linux:
Finished release [optimized + debuginfo] target(s) in 24.98s
real 0m25.151s
user 4m54.987s
sys 0m6.764s
# 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 should benchmark against Linux as well.
There's your problem.
Even Microsoft concedes that Windows is legacy technology now.
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)
Are you including download time? On my Ryzen 7 3700X, it's done in 17 seconds.
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.
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 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.
There isn't.
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.
This statement speaks volumes about your bias. You're immediately on the defensive and assuming we're attacking the M1 rather than the assumptions made in a test and it's methodology.
No one was implying that the M1's performance would tank. I specifically conjectured that perhaps x86, not M1, might have a penalty.
The original assertion made was that all x86 compiles were ~30% slower than the M1, but the benchmark was a ~20 compile. What happens if the compile is hours?
If the penalty is ~30% linear then a 60 minute compile on M1 is 80 minutes on x86. But if there's just a 10 second warmup penalty on x86 the compile time might only be 60 minutes + 10 seconds.
The truth is probably somewhere in between.
But that doesn't make any sense, as I previously asserted. That's just not how any of this works. x86 is not suffering a "penalty". It doesn't need time to "warmup". I already discussed my views (based on actual real world experience) on all of this, but you conveniently bypassed those statements.
> This statement speaks volumes about your bias. You're immediately on the defensive and assuming we're attacking the M1 rather than the assumptions made in a test and it's methodology.
It really doesn't speak volumes. The default position I've seen is for people to assume that new technology is just a gimmick, and that results are only being cherry picked. And that's exactly what you just said you were assuming ("the truth is probably somewhere in between"), so I was right to reach that conclusion. No one here (that I've seen) is claiming the M1 is the unequivocal performance champion in all things, but it does really well in some use cases that impress me as a developer.
If it's really just about test methodology, you would just look up other tests, or run your own. Putting out completely unfounded statements like "what if there's a fixed 10 second ding on x86?" doesn't move the conversation forward when the hardware and results are so readily available. It's just a way of attempting to cast doubt on results. There's little need for speculation at this point, but you continue to speculate in defense of your previous comment without apparently having any hands on experience with M1.
Where did you assert that in our thread?
> It really doesn't speak volumes.
It does, you immediately assume someone is attacking the M1 because we question someone's assertion that the M1 is 30 something percent faster based on one small compilation benchmark.
https://news.ycombinator.com/item?id=27189764
"[...] 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."
This is where I asserted that.
The only way there could be a "10 second penalty" is if the Intel processor just takes 10 seconds to warm up, and then it's on even footing after that point.
Intel processors takes milliseconds to change frequencies, so... clearly this is not a logical discussion point.
> It does, you immediately assume [...]
You actually misinterpreted my comment, possibly because you didn't read the rest of the paragraph that I copied above in this comment.
I didn't assume in that comment that anyone was "attacking M1" in the way you keep implying, based on the sentence fragment that you had cherry picked in your previous response. When I said that the M1 performance wouldn't tank, I clarified in that same paragraph that I meant this to be a relative measure compared to the Intel processor, since the Intel processor had its time to warm up and suddenly be super fast. If you read the whole paragraph, you should be able to see what I actually said.
If anything, I was defending Intel's Turbo Boost technology... which is the opposite of the conclusion you apparently jumped to.
I never implied that x86 would catch up or even surpass the M1. I was suggesting that x86 might have some sort of delayed start but that actual compilation might occur at a similar pace to the M1.
The OP had a single data point based on a sub 60 second execution of a small project and extrapolated it out to a 30+ minute compilation of a larger project for comparison. He suggested that on a graph of Compile Time based on Project Size the divergence in performance might be linear.
I was merely suggesting there might be something else at play causing a delayed start of compilation on the x86 side. You came in and authoritative shut me down and then tried to suggest that we were being vague with our use of the term linear.
Imagine two runners that can keep similar pace but one always starts the race with his shoes untied and has to lace up as part of the race. Once he's laced up he can start running and will keep pace with the other runner, who has a head start, but will always be behind. That's what I was suggesting. In this analogy the length of the race is irrelevant.
Correct. It is an extreme used as an illustration to point out that you can not simply take the time savings on one compile and assume it will save the same percentage on a longer compile. I am not sure why that is so difficult for you to comprehend, particularly since cptskippy has specifically said "The truth is probably somewhere in between."
But for something like compilation which is multithreaded obviously the higher core count will win.
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
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