Apple M1 vs. Ryzen 3900X vs. Intel I9 in Software Development(tech.ssut.me)
tech.ssut.me
Apple M1 vs. Ryzen 3900X vs. Intel I9 in Software Development
https://tech.ssut.me/apple-m1-chip-benchmarks-focused-on-the-real-world-programming/
466 comments
The fact that we are even able to realistically compare a CPU in an ultralight laptop with no fan to an i9 is absolutely amazing. To me that would be an upgrade even if performance is a complete wash.
Yeah seeing a MacBook Air beat an i9 is hilarious.
I think this should put arguments over X86 efficiency disadvantages to bed. The X86 is obviously a huge boat anchor. There is no other explanation for this monstrous of a performance efficiency gap... unless Apple has invented something fundamentally new that has never been done in the entire history of CPU design. I doubt that.
I think this should put arguments over X86 efficiency disadvantages to bed. The X86 is obviously a huge boat anchor. There is no other explanation for this monstrous of a performance efficiency gap... unless Apple has invented something fundamentally new that has never been done in the entire history of CPU design. I doubt that.
I doubt the instruction set is the only (or even the main) advantage M1 has. Apple just has been hiring some of the best talent in the field for a long time now that have been working on their phone/tablet chips and now used their talents on the M1.
There is a lot you can do to improve a CPU without changing the instruction set or manufacturing process just by doing a better job at designing the CPU itself. (look at Ryzen 5000 series with 15 to 20% IPC gain over the 3000/4000 series while staying on the same manufacturing process for example)
Basically there is a lot to gain just by doing a better design on the CPU itself. Also faster CPUs/GPUs allows one to build faster CPUs/GPUs just because as with more compute around you can run simulations faster/with more accuracy thus allowing faster development/better designs.
There is a lot you can do to improve a CPU without changing the instruction set or manufacturing process just by doing a better job at designing the CPU itself. (look at Ryzen 5000 series with 15 to 20% IPC gain over the 3000/4000 series while staying on the same manufacturing process for example)
Basically there is a lot to gain just by doing a better design on the CPU itself. Also faster CPUs/GPUs allows one to build faster CPUs/GPUs just because as with more compute around you can run simulations faster/with more accuracy thus allowing faster development/better designs.
Here's a really good article describing why the M1 chip is so fast. Tl;dr it's a beefy CPU with a massive reorder buffer, and a bunch of discrete subsystems (gpu, ml core, dsp, etc).
https://debugger.medium.com/why-is-apples-m1-chip-so-fast-32...
https://debugger.medium.com/why-is-apples-m1-chip-so-fast-32...
Not to mention that the M1 has a manufacturing node advantage (which can really help with perf-per-watt).
I think people should pay more attention to the LPDDR4X RAM that's tightly coupled to the CPU and likely has significantly less latency and more bandwidth than anything on the Ryzen or i9. This is critical to keeping their wide design fed, and if you swapped this out with standard DDR3200 you'd see some lackluster numbers.
Both Intel and AMD try to overcome the memory wall with larger caches and clever prefetching, which is going to chew up more die space and power than x86 decoders.
Both Intel and AMD try to overcome the memory wall with larger caches and clever prefetching, which is going to chew up more die space and power than x86 decoders.
Anandtech measured the ram latency at >90ns, which is not great:
https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...
The cache on the M1 is also massive. If Intel/AMD have clever prefetchers to make up for this, it looks like the M1 might be doing something more.
https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...
The cache on the M1 is also massive. If Intel/AMD have clever prefetchers to make up for this, it looks like the M1 might be doing something more.
I have been trying to explain to people that having the DRAM chips physically next to the SOC on the package does not actually meaningfully improve memory latency.
I get that people on this site are excited, but please be excited about the right things.
I get that people on this site are excited, but please be excited about the right things.
Yeah, speed of PCB transmission is ~8 inches (~20cm) per nanosecond. Which is about 2/3 of the classic "light-nanosecond", which is roughly a foot.
People seem to have dramatically missed the point here; it's almost certainly done for power reasons.
And also for silicon budget, probably: short distances require small interface transistors and thin wires compared to massive distances like 5cm.
The chip area can be re-used for compute-sized transistors and wires (much, much smaller than interface transistors and wires, so there can be many more of them).
The chip area can be re-used for compute-sized transistors and wires (much, much smaller than interface transistors and wires, so there can be many more of them).
Why would that RAM have less latency? Do you have any sort of a source for why you think that?
How would one benchmark memory performance (DRAM latency & bandwidth) on the various chips?
Above my pay grade! You probably operating with a fixed speed on M1 so you can't intentionally cripple it, but it would be interesting to see "What would this look like if Apple had paired it with standard DDR4-3200?". AMD's Zen core's are known to respond well to lower latency RAM, but in the PC space you're not getting anything close to what Apple has with the LPDDR4x on package. You could try benchmarking the Intel and Ryzen chips with DDR4 5000 and try carefully tuning the memory frequency and timing to find the right balance of bandwidth and latency.
> in the PC space you're not getting anything close to what Apple has with the LPDDR4x on package.
I mean, that's exactly how an 11th Gen Core laptop is constructed.
I mean, that's exactly how an 11th Gen Core laptop is constructed.
> but in the PC space you're not getting anything close to what Apple has with the LPDDR4x on package.
You can run basically any Intel CPU at DDR4-4266 without any issue. Or you can go thread ripper and laugh in quad channel memory. Or Intel x299 and triple-channel memory.
You don't have to tune anything, either, the RAM comes pre-tuned with the right timings in the XMP profile.
You can run basically any Intel CPU at DDR4-4266 without any issue. Or you can go thread ripper and laugh in quad channel memory. Or Intel x299 and triple-channel memory.
You don't have to tune anything, either, the RAM comes pre-tuned with the right timings in the XMP profile.
DDR5 is coming to consumer platforms probably 2022
this is a reasonable test: https://www.cs.virginia.edu/stream/ref.html
but it's pretty straightforward to just copy giant buffers in order/out of order and squint really hard at the results
but it's pretty straightforward to just copy giant buffers in order/out of order and squint really hard at the results
LPDDR4X-4266 memory and its right on the chip.
I'd really like to see what AMD could do with a huge die that combines 8 Zen 3 cores, 16 GB of LPDDR4X-4266, and their GPU all on a single chip.
I'm very excited about the performance that Apple has been able to generate with this silicon, but these tests don't put anything to bed.
You're giving up extreme choice and expandability for performance by going the M1 route. You can spend $1700 for a Mac Mini with 16 GB of RAM and a 2 TB SSD, but that's what you're stuck with. Forever. Until its time to buy a new computer. People who bought into AMD's AM4 platform at the start were able to go up from the 1000 series to the 3000 series, able to upgrade their RAM from nearly any size to 64 GB, and able to upgrade their SSDs by slotting in a new NVMe drive. To say nothing of the GPU, which for developers of specific solutions, is becoming a serious concern. Also if you game in your spare time, you're at a disadvantage not just due to the Apple ecosystem, but also limited by the GPU.
For most of us, our machines are disposable. Even though I still build myself a new workstation every 2-3 years, I never bother selling it, I just give it away to family because for me its not worth the hassle, and then I order $3-4000 in parts and build a new one all over again. So buying the new Mac Mini made sense for me, although I opted to go with the base model for $699 so I could evaluate it and determine if going "all-in" for a higher-end model made sense (it does), but not for one second am I under the illusion that this chip is going to be the death of x86.
I'd really like to see what AMD could do with a huge die that combines 8 Zen 3 cores, 16 GB of LPDDR4X-4266, and their GPU all on a single chip.
I'm very excited about the performance that Apple has been able to generate with this silicon, but these tests don't put anything to bed.
You're giving up extreme choice and expandability for performance by going the M1 route. You can spend $1700 for a Mac Mini with 16 GB of RAM and a 2 TB SSD, but that's what you're stuck with. Forever. Until its time to buy a new computer. People who bought into AMD's AM4 platform at the start were able to go up from the 1000 series to the 3000 series, able to upgrade their RAM from nearly any size to 64 GB, and able to upgrade their SSDs by slotting in a new NVMe drive. To say nothing of the GPU, which for developers of specific solutions, is becoming a serious concern. Also if you game in your spare time, you're at a disadvantage not just due to the Apple ecosystem, but also limited by the GPU.
For most of us, our machines are disposable. Even though I still build myself a new workstation every 2-3 years, I never bother selling it, I just give it away to family because for me its not worth the hassle, and then I order $3-4000 in parts and build a new one all over again. So buying the new Mac Mini made sense for me, although I opted to go with the base model for $699 so I could evaluate it and determine if going "all-in" for a higher-end model made sense (it does), but not for one second am I under the illusion that this chip is going to be the death of x86.
Well, Apple has managed to move all the way down to a 5nm process while Intel still hasn't made it past 14nm. AFAIK that's the largest limiting factor for Intel. I can't speak to why they have been stuck there for so long.
Leaving aside the fact that process size is a marketing term these days, I’m currently typing this on a previous-gen Macbook Air with a 10nm Intel CPU. They’re definitely not stuck on 14nm.
They are effectively stuck on 14nm. They are unable to produce 10nm chips at scale at an acceptable yield, and the power and performance characteristics are not as good as expected either.
There's a reason the only laptops getting 10nm are low-quantity premium laptops.
There's a reason the only laptops getting 10nm are low-quantity premium laptops.
> Leaving aside the fact that process size is a marketing term these days
There was a youtube video where the guy used a scanning electron microscope to compare gate sizes between 14nm intel and 7nm AMD and both were basically the exact same size.
The conclusion was that the term is useful only to compare a single companies product line against other offerings in that line (eg comparing Intel's 14nm to Intel's 20nm makes sense but comparing Intel to AMD based on node size is meaningless).
There was a youtube video where the guy used a scanning electron microscope to compare gate sizes between 14nm intel and 7nm AMD and both were basically the exact same size.
The conclusion was that the term is useful only to compare a single companies product line against other offerings in that line (eg comparing Intel's 14nm to Intel's 20nm makes sense but comparing Intel to AMD based on node size is meaningless).
I think you are speaking of der8auer and this video in particular: https://youtu.be/1kQUXpZpLXI?t=716
Yes! That’s the one, thanks. It was a very interesting video.
yes but GP is still correct in general if not in the specifics. Practically speaking they can fit way more transistors on the die which translates to more power for more types of things whether it's M1 or 888.
The i9 from the article is a 14nm "tweaked Skylake" part, i.e. the uarch has been on the market for ~five years.
> I can't speak to why they have been stuck there for so long.
Semiconductor manufacturer has been able to use refractive optics (lenses) for decades and decades. The biggest change until now was to immersion lithography as we started getting into UV. Now we're into EUV (extreme UV). Lenses no longer work, everything has to be done with reflective optics (and even then the mirrors get ablated over time). It's the biggest single change in lithography we've seen and Intel still hasn't been able to pull it off in volume.
Semiconductor manufacturer has been able to use refractive optics (lenses) for decades and decades. The biggest change until now was to immersion lithography as we started getting into UV. Now we're into EUV (extreme UV). Lenses no longer work, everything has to be done with reflective optics (and even then the mirrors get ablated over time). It's the biggest single change in lithography we've seen and Intel still hasn't been able to pull it off in volume.
I’m not sure about 5nm but I know they were targeting 7nm and something broke that set them back till 2022/23. Not looking good for intel
https://www.tomshardware.com/news/intel-announces-delay-to-7...
https://www.tomshardware.com/news/intel-announces-delay-to-7...
I think process node is overrated here. If the only thing that Intel was struggling with was process nodes and the rest of their designs were amazing, Apple would have probably stayed with them and encouraged them to outsource their chip fab work.
Apple is getting performance that matches the best of Intel has while beating the power draw of basically all they have.
And it's not just the CPU. The built in GPU of the MBA is surprisingly powerful, and the neural engine is beyond what Intel has.
Yes, Intel needs to get their chip fab back on track, but I also think they have issues with their chip designs (and perhaps something larger with x86).
Apple is getting performance that matches the best of Intel has while beating the power draw of basically all they have.
And it's not just the CPU. The built in GPU of the MBA is surprisingly powerful, and the neural engine is beyond what Intel has.
Yes, Intel needs to get their chip fab back on track, but I also think they have issues with their chip designs (and perhaps something larger with x86).
My intuition is that x86's wasted die space on instruction decoding, backwards compatibility, etc. can be spent on making bigger and wider cores, and this seems to be what M1 is doing.
However, there are still some other aspects to consider. One is Apple's process lead against both Intel and AMD. The next is the memory situation; it'll be interesting to see if increased latency from more conventional configurations will change the dynamics much. (I suspect no, but some people suspect yes.)
However, there are still some other aspects to consider. One is Apple's process lead against both Intel and AMD. The next is the memory situation; it'll be interesting to see if increased latency from more conventional configurations will change the dynamics much. (I suspect no, but some people suspect yes.)
The x86 space for decoding is tiny. The inefficiencies have to come from elsewhere and at least partially from the node difference. An architecturally big one is that x86 only implements SeqCst for atomics whereas looser memory models can allow multi-process programs to be written more efficiently (which they have been already for mobile).
In other words I think the problem has to do with the semantics of x86 more than the syntax of decoding x86.
In other words I think the problem has to do with the semantics of x86 more than the syntax of decoding x86.
This was explored in detail in another thread, it seems most of the gains are from looser memory ordering.
By the way, does someone knows where RISC-V stands regarding this ?
I think that Apple "just" [1] picked a very happy place in the parameter space: lower clock means that main memory (which is already lower latency than usual) is "nearer" to the cpu plus a larger L1 with a shorter latency (3 cycles). These (plus probably a larger amount of sustainable outstanding misses) imply that the cpu stalls less which means that they can sustain a larger ILP [2]. A better branch predictor (which is rumored to be best in class, although I haven't seen any in depth analysis) means that they can usefully have a larger reorder buffer and extract even more ILP and memory level parallelism. Finally the large width can take advantage of the extracted parallelism.
The weaker memory model should help extracting additional memory level parallelism, but I doubt that ordering has large impact. M1 is quite good even when running in TSO mode.
[1] of course they need to be commended for this, they went against the usual wisdom, probably because their CPU was designed to be low power first then high performance, not the other way around.
[2] typically the average ILP for normal applications is 1.5 instructions per cycle, but the variance is high, so if you reduce the amount of cycles the cpu is stalled, the ILP can go up fast.
The weaker memory model should help extracting additional memory level parallelism, but I doubt that ordering has large impact. M1 is quite good even when running in TSO mode.
[1] of course they need to be commended for this, they went against the usual wisdom, probably because their CPU was designed to be low power first then high performance, not the other way around.
[2] typically the average ILP for normal applications is 1.5 instructions per cycle, but the variance is high, so if you reduce the amount of cycles the cpu is stalled, the ILP can go up fast.
I agree with the rest, but memory latency is actually pretty poor on the M1:
https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...
https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...
You’re right. Like I said, atomics are one space. Another as you point out is that the memory architecture is pretty unique at providing high throughout and lower latency than traditional x86 architectures. I suspect Intel and AMD will adjust their roadmaps accordingly as a result of this new competition.
Where does the low-latency claim come from? Benchmarks do not validate it, giving main memory latency of around 100 ns.
Apparently you are right, but because of the lower clock, main memory is still closer in cycles. It would also be interesting to know the amount of outstanding main memory references.
Yes I agree, it's more the semantics and the legacy of x86 (page sizes, MMU, memory models - even though Rosetta still runs faster than x86) than simply decoding.
It’s not the instruction decoder that wastes die space. In fact, it’s less than 5% of the die (on Skylake).[0]
[0]: https://pbs.twimg.com/media/EXFJLebXkAYkXTr?format=jpg&name=...
In case that link dies, it’s from [1] which is linked from [2]
[1]: https://mobile.twitter.com/GPUsAreMagic/status/1256866465577...
[2]: https://travisdowns.github.io/blog/2020/05/26/kreg2.html
[0]: https://pbs.twimg.com/media/EXFJLebXkAYkXTr?format=jpg&name=...
In case that link dies, it’s from [1] which is linked from [2]
[1]: https://mobile.twitter.com/GPUsAreMagic/status/1256866465577...
[2]: https://travisdowns.github.io/blog/2020/05/26/kreg2.html
> it’s less than 5% of the die
It would be equally fair to say that the same die uses less than 5% of it's space for the integer ALUs. It could also be said that the decode unit is so complex that it takes as much die space as all the integer ports put together.
SRAM may use most of the die, but it isn't using huge amounts of power most of the time as it's static. Those big SIMD units are also powered off when not used (no doubt it's the same with the other ALUs).
In contrast, the entire 5% of the die that makes up the decoder never power gates and is always running flat out. By size it's the same as leaving all your integer cores running full-out all the time.
The bigger issue seems to be that neither AMD nor Intel have been able to make those units much wider over the years which puts a hard limit on total throughput (they've hinted that the power cost on widening the decoder is very big which would mean loads of power used for diminishing returns).
It would be equally fair to say that the same die uses less than 5% of it's space for the integer ALUs. It could also be said that the decode unit is so complex that it takes as much die space as all the integer ports put together.
SRAM may use most of the die, but it isn't using huge amounts of power most of the time as it's static. Those big SIMD units are also powered off when not used (no doubt it's the same with the other ALUs).
In contrast, the entire 5% of the die that makes up the decoder never power gates and is always running flat out. By size it's the same as leaving all your integer cores running full-out all the time.
The bigger issue seems to be that neither AMD nor Intel have been able to make those units much wider over the years which puts a hard limit on total throughput (they've hinted that the power cost on widening the decoder is very big which would mean loads of power used for diminishing returns).
It isn't so much the decoder space, but the decoder complexity that is the disadvantage of x86 chips. The problem is that the instructions have varying lengths. Only when it has decoded an instruction, the chip knows where the next instruction starts. ARM-instructions are all the same length, so the instructions can be decoded in parallel without "knowing" the previous instruction. That lets Apple go much wider (8 instead of 4) with the instruction decoders.
vmception(2)
Imagine AWS launching ec2 instances with M1 chips!
They recently announced the mac.metal instance type for EC2 instances[0]. They currently only have Intel instances but I can’t see why the newer M1 instances aren’t coming soon.
[0] https://aws.amazon.com/about-aws/whats-new/2020/11/announcin...
[0] https://aws.amazon.com/about-aws/whats-new/2020/11/announcin...
They are coming, but they will be crippled because of Apple licensing terms. The minimum rental period is 24 hours (every time you turn it on) so it's quite useless for e.g. occasional build.
They have graviton, which is already more efficient by a huge margin (against intel per dollar).
More efficient than Intel i-series or more efficient than M1?
more efficient per dollar against their intel counterparts.
AWS can set their own price (or subsidize it to keep people on their cloud), more efficient per $ is not really a good way to judge how good is the chip, though it is a good measure for how much money will stay in your pocket.
True, but I believe graviton is still not like M1. Do they support i386 / backward compatible?
M1 is not i386 compatible. macOS uses a translation layer through Rosetta 2 for x86 compatibility.
Sorta - There is translation layer in software but the reason the M1 is so fast at executing x86 code is that it has hardware support for switching to the x86 memory model. This is something no other ARM processor I'm aware of has.
Is this true? I didn't see this detail anywhere I looked. If you have a source that would be interesting.
It was previously discussed here https://news.ycombinator.com/item?id=25233554 but I can't find the primary source linked anywhere.
> Do they support i386
No. But for many use cases that’s not a big deal, since you’re likely to be running Linux & other open source software that already has ARM versions or can be recompiled.
No. But for many use cases that’s not a big deal, since you’re likely to be running Linux & other open source software that already has ARM versions or can be recompiled.
[deleted]
Just a quick note, the MacBook Air is by no means "ultralight" even by Apple standards, 2017 MacBook for example was more than twice lighter. Thinkpad laptops are also measurably lighter than any current generation MacBook.
Yes, Apple's current lineup is a little confusing. The 13" Pro and 13" Air are so similar, and almost the same weight.
I still use a 12" MacBook, and it's just amazingly small and light. If Apple makes a 12" MacBook with a M1, it would be awesome. A dream machine for me.
I still use a 12" MacBook, and it's just amazingly small and light. If Apple makes a 12" MacBook with a M1, it would be awesome. A dream machine for me.
> M1
I don't have any insider knowledge but I am fully convinced (and so are many others) that we will see a newer Apple ARM based processor before the end of 2021. If you are a programmer and you have a machine to work on, I'd say hold out for the next one.
I don't have any insider knowledge but I am fully convinced (and so are many others) that we will see a newer Apple ARM based processor before the end of 2021. If you are a programmer and you have a machine to work on, I'd say hold out for the next one.
Apple hardware resells extremely well and if you don't want to deal with the hassle of reselling privately you can can also trade it in for a decent return.
If you're not on a super tight budget it's not terrible to just pick up the new machine and swap it out for the next one that ships if you want to.
If you're not on a super tight budget it's not terrible to just pick up the new machine and swap it out for the next one that ships if you want to.
In my mind the resell value of intel macbooks dropped significantly with the M1 release. Not sure if that's reflected in the second hand market already, but I think it will.
I'm curious about this too. I actually think it won't because even with the huge amount of marketing for this new chip that apple is doing, the average consumer doesn't explicitly care about the cpu.
Agreed! Even dreamier if they bring back the magsafe and upgrade to the current keyboard with function keys.
> If Apple makes a 12" MacBook with a M1, it would be awesome.
I wish Apple would make everything" MacBooks with M1. I hate that I have to wait another year or whatever for a 15/16" screen and will have to pay a measurable weight penalty to get it when nothing stops them from making a 15" ultralight model now that they don't need fans for stunning performance.
I wish Apple would make everything" MacBooks with M1. I hate that I have to wait another year or whatever for a 15/16" screen and will have to pay a measurable weight penalty to get it when nothing stops them from making a 15" ultralight model now that they don't need fans for stunning performance.
They might go with a processor bump for the 15”. And maybe more thermal headroom and an external GPU. Hard to predict.
But most people don't need or even care about those things. Making the MB or Air body bigger (not thicker) and just increasing screen, battery, and heatsink size proportionally while keeping it fanless would knock everything else out today for like 99% of people.
I am typing this on M1 Air, and it's noticeably smaller and lighter than our 2013 MB Air. I'd say that in terms of size it's quite close to 12" Mb which we owned previously, and maybe just a tiny bit heavier.
> I'd say that in terms of size it's quite close to 12" Mb which we owned previously
If true, then neither are close to the 2017 12" MB.
> and maybe just a tiny bit heavier.
It's almost a pound heavier.
If true, then neither are close to the 2017 12" MB.
> and maybe just a tiny bit heavier.
It's almost a pound heavier.
[deleted]
The X1 Carbon, which is what I assume you're referring to with Thinkpad, is 2.6Lbs vs 2.8Lbs for the 2020 Macbook Air.
That's 90g of difference ... I'd say that qualifies for Ultralight still.
That's 90g of difference ... I'd say that qualifies for Ultralight still.
The new X1 nano is 907g (1.99 lbs), so the Macbook Air at 1.29kg is 42% heavier.
https://www.lenovo.com/us/en/coming-soon/ThinkPad-X1-Nano/p/...
https://www.lenovo.com/us/en/coming-soon/ThinkPad-X1-Nano/p/...
Still running last-century processors though.
Only in the sense that your car is running on 4000 BC wheels.
From the page linked to:
> 11th Generation Intel® Core™ i5-1130G7 Processor
From https://ark.intel.com/content/www/us/en/ark/products/series/...
> Launch Date: Q3'20
From the page linked to:
> 11th Generation Intel® Core™ i5-1130G7 Processor
From https://ark.intel.com/content/www/us/en/ark/products/series/...
> Launch Date: Q3'20
Ah, wasn't aware of that!
Current gen X1 Carbon is 2.4 lbs: https://www.lenovo.com/us/en/laptops/thinkpad/thinkpad-x1/X1...
> more than twice lighter.
Under half the weight?
Under half the weight?
That's not true though, the air weighs at 1.27 kg whereas the 12" macbook weighs at 0.92 kg.
That's about a quarter lighter but not anywhere near half.
That's about a quarter lighter but not anywhere near half.
What does 'more than twice lighter' even mean?
It surely wasn't less than half as heavy. So what do you mean?
It surely wasn't less than half as heavy. So what do you mean?
You're not wrong but the article is still a 9th gen laptop i9. A desktop i9 is quicker - https://cpu.userbenchmark.com/Compare/Intel-Core-i9-9880H-vs....
I still don't understand why people can't get that not all i9s are the same. That's literally what this title is implying ... Which isn't even the article's title ... Maybe someone will edit it so people stop assuming they mean the i9-10900k ...
Also i9 doesn't mean "fast" it just means it is the most expensive of its generation. You will get much closer to M1 performance using a mobile 11th gen i7 than with any i9.
Intel likely intended people to mix up the processors like this because they could easily have marketed a distinction between them.
But the Ryzen 3900X is a desktop processor, right? This is crazy - definitely was not expecting the M1 to be _better_ than the 3900X.
It’s a desktop processor, but also last generation. The latest Ryzens are the 5xxxx series, and the performance improvement is substantial.
also ... single core performance
m1, like the a* chips are great at single core performance m1, like the a* chips are underwhelming at multi-core performance last gen ryzen was competitive at single core performance, and great at multicore current gen ryzen is great at both
m1, like the a* chips are great at single core performance m1, like the a* chips are underwhelming at multi-core performance last gen ryzen was competitive at single core performance, and great at multicore current gen ryzen is great at both
This isn't correct.
A fair number of these benchmarks were multithreaded, and the M1 held its own very well, despite being at a substantial disadvantage (8 threads (only 4 on performance cores) for M1 versus 24 for Ryzen 3900X).
That said, single threaded performance is extremely important, since not everything can be parallelized. Amdahl's Law, eh?
Don't worry though, I'm sure Apple Silicon is coming with many more cores. Amazon's Graviton2 shows how ARM can perform with massive core counts...
As to the current Ryzen (5000 series), it's a great chip and what I'm planning to use in a new build, but it also has a 105W power budget. We'll see what Apple produces for its desktop entries soon enough!
A fair number of these benchmarks were multithreaded, and the M1 held its own very well, despite being at a substantial disadvantage (8 threads (only 4 on performance cores) for M1 versus 24 for Ryzen 3900X).
That said, single threaded performance is extremely important, since not everything can be parallelized. Amdahl's Law, eh?
Don't worry though, I'm sure Apple Silicon is coming with many more cores. Amazon's Graviton2 shows how ARM can perform with massive core counts...
As to the current Ryzen (5000 series), it's a great chip and what I'm planning to use in a new build, but it also has a 105W power budget. We'll see what Apple produces for its desktop entries soon enough!
All these gains will be entirely swallowed by software in a few years.
The purpose of hardware engineering is to make up for the short falls of software engineers.
Electron apps or worse.
Not just Electron apps. I've seen people on Twitter gushing about how seamless and flicker-free is switching between screens and resolutions on M1. And yet, there's literally no reason why it can't be done today, now, on the existing hardware.
Instant waking from sleep was one of the key points in M1's presentation. Something my 2007 model Macbook Pro could do. But then the subsequent releases of MacOS just couldn't do that. Despite significant increases in disk speed, and CPU speed, and RAM speed.
We are effecivey running supercomputers. And we can't seem to be able to do anything with them.
Instant waking from sleep was one of the key points in M1's presentation. Something my 2007 model Macbook Pro could do. But then the subsequent releases of MacOS just couldn't do that. Despite significant increases in disk speed, and CPU speed, and RAM speed.
We are effecivey running supercomputers. And we can't seem to be able to do anything with them.
> But then the subsequent releases of MacOS just couldn't do that.
How instant? My late 2016 MBP wakes in around a second. My 2014 Mac mini usually takes only a few seconds.
How instant? My late 2016 MBP wakes in around a second. My 2014 Mac mini usually takes only a few seconds.
As instant as in the keynote video. IIRC around the time of Lion I started seeing a progress bar as it was coming out of sleep.
Now, especially if you require password you need to wait a second or so after it wakes up, because input is no longer immediately available. And then it takes some time to actually wake up and start the window server etc.
Now, especially if you require password you need to wait a second or so after it wakes up, because input is no longer immediately available. And then it takes some time to actually wake up and start the window server etc.
What makes you think AMD/Intel can do instant display resolution changes?
What exactly prevents them from doing just that? 3.2 GHz not enough to negotiate screen resolution? HDMI/DP link that M1 produces is some otherworldly HDMI/DP not available to anyone else?
I have an example right here, in front of me. I have a Dell monitor. My Macbook Pro is connected to it via Thunderbolt/USB-C->HDMI. My Windows box is connected to it via DP.
So, I'm on my Windows box, playing a game. I turn on my Macbook Pro, and it shows me a proper resolution on the laptop screen. The laptop sees that the display is on, and I see that many windows are missing because they are on the other screen. So, I switch my display from DP (coming from Windows) to HDMI (coming from my Macbook Pro).
The only thing that changes is the source input to the display.
And yet. Macbook takes up to 10 seconds to renegotiate the resoltion again. First it slowly disconnects from the display, screws up the resolution, brings all the windows to the laptop screen. Then it reconnects to the display, renegotiates the resolution and restores the windows as they are supposed to be.
Why? And what is so magical about the M1 CPU that it seemingly can do this in an instant? There's nothing magical: whoever implements all this crap simply doesn't care. And in a couple of years M1 (or M1 X Pro whatever) will forget how to to that just as MacOS forgot how it could instantly wake up from sleep 12 years ago.
I have an example right here, in front of me. I have a Dell monitor. My Macbook Pro is connected to it via Thunderbolt/USB-C->HDMI. My Windows box is connected to it via DP.
So, I'm on my Windows box, playing a game. I turn on my Macbook Pro, and it shows me a proper resolution on the laptop screen. The laptop sees that the display is on, and I see that many windows are missing because they are on the other screen. So, I switch my display from DP (coming from Windows) to HDMI (coming from my Macbook Pro).
The only thing that changes is the source input to the display.
And yet. Macbook takes up to 10 seconds to renegotiate the resoltion again. First it slowly disconnects from the display, screws up the resolution, brings all the windows to the laptop screen. Then it reconnects to the display, renegotiates the resolution and restores the windows as they are supposed to be.
Why? And what is so magical about the M1 CPU that it seemingly can do this in an instant? There's nothing magical: whoever implements all this crap simply doesn't care. And in a couple of years M1 (or M1 X Pro whatever) will forget how to to that just as MacOS forgot how it could instantly wake up from sleep 12 years ago.
You haven't proved it's possible to do any of that on Intel hardware - sleep and display config are both very HW driven. Software can't do everything.
- Did the displays change for M1? No.
- Did the protocols such as HDMI and DP change for M1? No.
- Did the Extended Display Identification Data [1] change? No.
That leaves two things:
- The OS that matches the extended data against what the user wants
If the OS is responsible, then there's nothing stopping others from doing what Big Sur does.
- graphics cards that actually pump out pixels and have their own support for possible resolutions
If graphics card is responsible, you're asking me to believe that M1 is driven by fairy pixel dust and has some magical powers that are absolutely impossible on any other hardware?
[1] https://en.wikipedia.org/wiki/Extended_Display_Identificatio...
- Did the protocols such as HDMI and DP change for M1? No.
- Did the Extended Display Identification Data [1] change? No.
That leaves two things:
- The OS that matches the extended data against what the user wants
If the OS is responsible, then there's nothing stopping others from doing what Big Sur does.
- graphics cards that actually pump out pixels and have their own support for possible resolutions
If graphics card is responsible, you're asking me to believe that M1 is driven by fairy pixel dust and has some magical powers that are absolutely impossible on any other hardware?
[1] https://en.wikipedia.org/wiki/Extended_Display_Identificatio...
One can easily foresee this actually happening if chip designs start to diverge from the standard and the only common thing is that you can run a browser on it.
I think they're more light than ultralight. Otherwise the performance stands.
LG Gram 2020: 2.07 lbs
MacBook 2017: 2.03 lbs
MacBook Air 2020: 2.8 lbs
MacBook Pro 2020: 3.0 lbs
LG Gram 2020: 2.07 lbs
MacBook 2017: 2.03 lbs
MacBook Air 2020: 2.8 lbs
MacBook Pro 2020: 3.0 lbs
Apple deliberately kept the form factors of these the same for this launch. It will be interesting seeing where they go from here form factor wise.
Also... I suspect benchmarking the LG or the 12" MacBook versus the Air would be pretty humiliating.
Also... I suspect benchmarking the LG or the 12" MacBook versus the Air would be pretty humiliating.
MacBook Air 2019 (Intel): 2.75
MacBook Pro 2019 (Intel): 3.02
As far as I see the M1 models aren't heavier than the Intel ones? But run much longer before they have to be recharged, spending much less power.
MacBook Pro 2019 (Intel): 3.02
As far as I see the M1 models aren't heavier than the Intel ones? But run much longer before they have to be recharged, spending much less power.
Leaving aside the x86 vs Arm efficiency debate, the key takeaway with the M1 for me is that the Arm licensing business model has allowed Apple to innovate on top of the Arm ISA and create something genuinely impressive.
I know the x86 ecosystem is more open but the costs of being locked into the x86 duopoly for so long have been invisible. The M1 is making them visible.
I know the x86 ecosystem is more open but the costs of being locked into the x86 duopoly for so long have been invisible. The M1 is making them visible.
> Leaving aside the x86 vs Arm efficiency debate
Just to clarify, there was no debate about efficiency in terms of work per Watt for a very long time now. Arm wins in this regard, because it is designed for efficiency. The remaining questions were question is how fast can Arm go? Can it compete with x86 performance-wise?
Just to clarify, there was no debate about efficiency in terms of work per Watt for a very long time now. Arm wins in this regard, because it is designed for efficiency. The remaining questions were question is how fast can Arm go? Can it compete with x86 performance-wise?
I think we know the answer to the final question now!
So, does that mean we should be looking at Risc V as the future of computing?
I briefly tested the base M1 Air with 8gb of ram (bought for my wife) - enough to get my day-to-day stuff up and running. I’m comparing a 2017 MacbookPro, dual-core i5 with 16GB of RAM.
Brew: under Rosetta everything seems to work
Java/Clojure: the AdoptOpenJDK works fine but the performance is not good; similar numbers with my old machine. The Azul ARM JDK is literally twice as fast. The jsass library depends on a native binary which doesn’t exist for ARM which is a roadblock.
MongoDB and Redis work fine under Rosetta.
I didn’t have more time as I had to send it back because of a wrong keyboard (I’ve put in the wrong order) but something missing from the various benchmarks is the clear wins in UI zippiness, and the silence and relative lack of heat when the machine is taxed.
I’m looking forward to the replacement arriving so I can try a video call.
Brew: under Rosetta everything seems to work
Java/Clojure: the AdoptOpenJDK works fine but the performance is not good; similar numbers with my old machine. The Azul ARM JDK is literally twice as fast. The jsass library depends on a native binary which doesn’t exist for ARM which is a roadblock.
MongoDB and Redis work fine under Rosetta.
I didn’t have more time as I had to send it back because of a wrong keyboard (I’ve put in the wrong order) but something missing from the various benchmarks is the clear wins in UI zippiness, and the silence and relative lack of heat when the machine is taxed.
I’m looking forward to the replacement arriving so I can try a video call.
Zoom works even better on an M1 than Intel Mac: https://screenrant.com/m1-macbook-zoom-calls-intel-apple/
I had a bunch of training videos packed as zips — about 40, and sizes were from tens of megabytes to a couple of gigabytes.
So I selected them all, and pressed cmd+o which launched unpacking. They were processed 4 at a time, but for a whole time CPU, according to iStat menu, was 90-93% idle.
I'm still extremely suspicious of all these benchmarks, because they don't seem to correlate with my real-world experience.
All these benchmarks claim to be comparing real-world applications, but I don't trust them because of what they always show with regards to mobile i9 and desktop Ryzen.
I've got a Intel Macbook Pro, and a Ryzen desktop. When I'm using them for development, my Ryzen is absolutely wiping the floor with the Macbook, Android builds complete in a fraction of the time, and I barely ever have to wait for anything to complete. The story is much the same with almost any development tool or process I use.
Yet benchmarks like these show comparatively minor performance differences between the two. I just get the impression these benchmarks are being cherrypicked, or are "nerfed" in some way on multicore systems.
All these benchmarks claim to be comparing real-world applications, but I don't trust them because of what they always show with regards to mobile i9 and desktop Ryzen.
I've got a Intel Macbook Pro, and a Ryzen desktop. When I'm using them for development, my Ryzen is absolutely wiping the floor with the Macbook, Android builds complete in a fraction of the time, and I barely ever have to wait for anything to complete. The story is much the same with almost any development tool or process I use.
Yet benchmarks like these show comparatively minor performance differences between the two. I just get the impression these benchmarks are being cherrypicked, or are "nerfed" in some way on multicore systems.
> I'm still extremely suspicious of all these benchmarks, because they don't seem to correlate with my real-world experience.
Couple that with using the latest and greatest from Apple, alongside the previous Ryzen generation when substantial improvements are happening each generation.
> You may wonder why I used 3900X instead of Ryzen 5000-series CPUs: Because I don't have it.
In addition, 3200MT/s RAM is not adequate for Ryzen because that sets the IF to 1600MHz which leaves a huge amount of performance on the floor, assuming OP enabled XMP at all.
Furthermore, those results are suspect because of OP is (as you pointed out) incorrectly testing single-core performance, Intel should be besting AMD for that generation (only the latest generation is superior across all dimensions).
This is fan-made marketing material.
Performance-to-watt would have shown the true advantage of M1, not this cherry-picked nonsense.
Couple that with using the latest and greatest from Apple, alongside the previous Ryzen generation when substantial improvements are happening each generation.
> You may wonder why I used 3900X instead of Ryzen 5000-series CPUs: Because I don't have it.
In addition, 3200MT/s RAM is not adequate for Ryzen because that sets the IF to 1600MHz which leaves a huge amount of performance on the floor, assuming OP enabled XMP at all.
Furthermore, those results are suspect because of OP is (as you pointed out) incorrectly testing single-core performance, Intel should be besting AMD for that generation (only the latest generation is superior across all dimensions).
This is fan-made marketing material.
Performance-to-watt would have shown the true advantage of M1, not this cherry-picked nonsense.
Are your real-world applications running on the same operating system?
According to a thread on RWT (https://www.realworldtech.com/forum/?threadid=197081&curpost...), macOS is much slower than Linux on the same hardware for some tasks like building software. If your Ryzen desktop is running Linux and your Macbook Pro is running macOS, that would be enough to explain at least part of the speed difference.
According to a thread on RWT (https://www.realworldtech.com/forum/?threadid=197081&curpost...), macOS is much slower than Linux on the same hardware for some tasks like building software. If your Ryzen desktop is running Linux and your Macbook Pro is running macOS, that would be enough to explain at least part of the speed difference.
Yes, for that reason it'd be amazing if one could run Linux on M1 hardware. Despite some old Intel models were great for this purpose and Linus has shown some interest, I'm not holding my breath.
It'd be nice if we saw some good competing CPUs. Nvidia is in my opinion is well positioned midterm due to the acquisition of ARM. But I'd prefer AMD due to openness and staying within the PC standard.
It'd be nice if we saw some good competing CPUs. Nvidia is in my opinion is well positioned midterm due to the acquisition of ARM. But I'd prefer AMD due to openness and staying within the PC standard.
In my experience of the last several years, the MacOS filesystem layer for lots of tiny files seems to be much slower than Linux. In our app, `rm -rf node_modules` (75,000 files, 1.1GB) takes about 10x longer on MacOS than it does on Linux (btrfs, zfs, ext4 all similar). `yarn install` has a similar difference between the two. I'd imagine most compiling tasks involving lots of tiny files would be impacted by the filesystem performance as well, hamstringing the performance of the M1.
However it may not be fair comparison as apple has no incentive to support optimization outside their stack. A skewed better performance in OSX is not just about the processor but about their stack preferring one arch.
Benchmark for OS+CPU stack should be their best combination not where one vendor has advantage.
Benchmark for OS+CPU stack should be their best combination not where one vendor has advantage.
This bit from the article might bring things into focus:
> "I add the following comment as of Dec 14: we care how fast our dev computer runs. the multi-core advantage of 3900X is useless for most of the benchmarks here that don't represent the real-world production performance at all but devs usually work on their laptops, desktops, etc most of the time so I think such real-world development performance benchmarks make it worthwhile though. of course, Ryzen 3900X will perform way better than M1 and Intel when it comes to production, mostly achieved by parallelizing."
> "I add the following comment as of Dec 14: we care how fast our dev computer runs. the multi-core advantage of 3900X is useless for most of the benchmarks here that don't represent the real-world production performance at all but devs usually work on their laptops, desktops, etc most of the time so I think such real-world development performance benchmarks make it worthwhile though. of course, Ryzen 3900X will perform way better than M1 and Intel when it comes to production, mostly achieved by parallelizing."
That explanation doesn't make a lot of sense, though. Like, I mostly do web-dev type stuff these days and my 3900X is alarmingly busy. Background compiles, entirely too many Chromium (or Electron) threads, all my other random running applications--the thing is significantly snappier even than the 2600X I replaced it with, and it's gotten to the point where using a laptop shy of a desktop replacement is pretty aggravating.
(I'm not interested in going back to MacOS so I'm not really looking at the M1 as anything other than intellectually interesting at the moment, but if I were it certainly at least seems like it might compete there.)
(I'm not interested in going back to MacOS so I'm not really looking at the M1 as anything other than intellectually interesting at the moment, but if I were it certainly at least seems like it might compete there.)
I agree. Though much of the writing on this benchmark/ blog seems confusing to me and the charts are all over the place in terms of style as well.
They're mostly some weird "java bench" "python bench" thingies rather than multicore builds of large C++/Rust/etc projects
In laptops, the performance of the CPU in sustained use is heavily tied to the cooling solution. Almost all laptops will hit a performance ceiling due to thermal throttling. A desktop is at a massive advantage here.
There are also potentially OS differences or other config differences. You'd need to normalize everything to get an accurate picture when comparing the two CPUs.
There are also potentially OS differences or other config differences. You'd need to normalize everything to get an accurate picture when comparing the two CPUs.
But desktop cores use vanishingly small amounts of power for single-threaded tasks.
The only time you really run into thermal-limits on desktops (or laptops) is when you're hitting SIMD across many cores: 16-thread or 32-thread tasks with AVX and the like.
The only time you really run into thermal-limits on desktops (or laptops) is when you're hitting SIMD across many cores: 16-thread or 32-thread tasks with AVX and the like.
They're talking about a difference in real world dev use. My Macbook Pro thermal throttles just running Chrome sometimes (which is always running while I develop). If I started a single threaded compile alongside that, it most definitely would run slower.
Multi-threaded tasks rarely exist in the wild. Compiling a project runs multiple processes at once, which is strictly better because it doesn’t need synchronization.
Your Ryzen probably comes with a Cooler (wraith prism). The CPU slows down considerably when it gets hot. Also, if you built the thing yourself, you might have added a super fast RAM, Motherboard, Nvme, and a capable graphic card.
Comparing Desktop to Laptop is Apple to Oranges. Otherwise the desktop market will no longer exist.
Comparing Desktop to Laptop is Apple to Oranges. Otherwise the desktop market will no longer exist.
that doesn't address any of his comparisons. the person doing these benchmarks also had a cooler, fast ram, motherboard has no impact, mac air has FASTER ram and a good ssd also.
How do you know? Parent didn't specify how fast his RAM is. The new macbook air is definitively fast but you could get something custom built that's faster (4400Mhz)
Same for me.
I have a Ryzen 5 and it feels about 3x faster than anything else in the house, and it's not even the most expensive chip in the house.
Next year definitely getting another Amd chip to upgrade my now old ryzen 5. Not touching Intel again in a long time.
Me too. I did a test rust compile to quantify the difference. A project that takes 2 minutes on my old 2016 MacBook Pro takes 20 seconds on my new ryzen 5800 desktop machine. And everything launches instantly. It’s an absolute breath of fresh air and I love it.
keep in mind that you should not use your 2016 MacBook with an external monitor (without clasmshell)
Except the parent poster is comparing Intel macbooks with a ryzen. He's not comparing M1 arm chips like the post. He's mistaken.
The amazing thing here if the claims are true is that a simple macbook air has performance on par with a full blown Ryzen desktop.
The amazing thing here if the claims are true is that a simple macbook air has performance on par with a full blown Ryzen desktop.
Yeah, those benchmarks seems to be highly biased over non-multicore applications.
The geekbench showed pretty much the same, M1 beats 3900X on single core performance, but only have 0.5 on overall multi-core score.
https://browser.geekbench.com/v5/cpu/compare/5326018?baselin...
This isn't a benchmark that "focused on the real-world programming", it's more of a benchmark on single core performance.
https://browser.geekbench.com/v5/cpu/compare/5326018?baselin...
This isn't a benchmark that "focused on the real-world programming", it's more of a benchmark on single core performance.
Would you also be able to run some of these?
They're publicly available; the more datasets we have the better picture we get.
They're publicly available; the more datasets we have the better picture we get.
So, I picked out a couple that I could run without installing too much extra:
Ryzen 3900X:
antd-admin webpack build: ~23 seconds. Not surprising, it's just single core.
golang.org/x/benchmarks, BenchmarkBuild-8: 4.61 seconds, so far off the value of 19.65s in the article that I feel I'm getting some suspicions confirmed...
Ryzen 3900X:
antd-admin webpack build: ~23 seconds. Not surprising, it's just single core.
golang.org/x/benchmarks, BenchmarkBuild-8: 4.61 seconds, so far off the value of 19.65s in the article that I feel I'm getting some suspicions confirmed...
well he used bad ram and didn't specify his ssd.
basically compilation is cpu+ssd+memory so if one of these suck you get what he did. a good cpu with garbage components.
not sure why somebody buys an X5xx mainboard and uses 3200mhz memory (which he hopefully ran in dual channel...)
also my macbook pro is slower.
also my macbook pro is slower.
> not sure why somebody buys an X5xx mainboard and uses 3200mhz memory
Because of the assumption that expensive is better.
For those who don't know: X5xx boards are better for overclocking as they typically have better VRMs (stable on-board power supply). In addition those boards have better memory traces, increasing the chances that you can overclock memory (beyond XMP) and tighten memory timings. On my 3950x this all resulted in about a 15% performance uplift (compared to XMP enabled alone).
If Apple were to ever use AMD hardware, they would likely use a B450 - it is perfectly capable of running all the components to spec.
Because of the assumption that expensive is better.
For those who don't know: X5xx boards are better for overclocking as they typically have better VRMs (stable on-board power supply). In addition those boards have better memory traces, increasing the chances that you can overclock memory (beyond XMP) and tighten memory timings. On my 3950x this all resulted in about a 15% performance uplift (compared to XMP enabled alone).
If Apple were to ever use AMD hardware, they would likely use a B450 - it is perfectly capable of running all the components to spec.
> that I feel I'm getting some suspicions confirmed...
Be careful. Benchmarking is hard. Before assuming malice, try to control for other variables.
Be careful. Benchmarking is hard. Before assuming malice, try to control for other variables.
I've tried
But the instructions are not clear.
Take for example the als benchmark for java renaissance.
It has a lot of options, one of them used to not force GC.
Was it set?
What version of Java?
I'm running openjdk 11.
When I launched it it gave me this warning
And how much?
There are other warnings complaining about lacking some additional library and switching to default, but what really surprised me is that on this particular laptop that mounts an Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz with 8 cores, a CPU at least 5 years old, I could beat the i9 benchmark.
The als benchmark for the i9 completed in 3581.838 ms, on my (very old) laptop the running time was 3533.964 ms.
Raw data from here (https://docs.google.com/spreadsheets/d/1g4U7LAImfEcXRihJbySZ...)
Tab "Java Renaissance (Chart)"
Col O, Row 4
But the instructions are not clear.
Take for example the als benchmark for java renaissance.
It has a lot of options, one of them used to not force GC.
Was it set?
What version of Java?
I'm running openjdk 11.
When I launched it it gave me this warning
20/12/14 18:55:20 WARN NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
And how much?
There are other warnings complaining about lacking some additional library and switching to default, but what really surprised me is that on this particular laptop that mounts an Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz with 8 cores, a CPU at least 5 years old, I could beat the i9 benchmark.
The als benchmark for the i9 completed in 3581.838 ms, on my (very old) laptop the running time was 3533.964 ms.
Raw data from here (https://docs.google.com/spreadsheets/d/1g4U7LAImfEcXRihJbySZ...)
Tab "Java Renaissance (Chart)"
Col O, Row 4
Share benchmarks of your setup then.
>I've got a Intel Macbook Pro, and a Ryzen desktop.
Read the title. It's Apple M1, these are apple arm chips NOT intel chips. Your "real-world experience" doesn't correlate because you're comparing Apple Intel macbooks with Intel desktops.
You need to compare the new Apple M1 macbooks with ARM chips to feel the difference.
Read the title. It's Apple M1, these are apple arm chips NOT intel chips. Your "real-world experience" doesn't correlate because you're comparing Apple Intel macbooks with Intel desktops.
You need to compare the new Apple M1 macbooks with ARM chips to feel the difference.
You misunderstood parent. The benchmark shows i9 vs. Ryzen (in addition to the M1), which does not correlate with parent's experience.
> Just Buy M1 if you'd like to have a low-power, long-lasting, quiet, and performant dev machine.
If your development environment/tooling/workflow does not gain any real advantage from more CPU cores. Also your data must fit in the 16GB of RAM as offloading any workload to disk will kill the performance and you cannot add more.
The M1 has excellent single core performance so any task that is mainly single threaded will do really well on it.
If your development environment/tooling/workflow does not gain any real advantage from more CPU cores. Also your data must fit in the 16GB of RAM as offloading any workload to disk will kill the performance and you cannot add more.
The M1 has excellent single core performance so any task that is mainly single threaded will do really well on it.
M1 has 4 big and 4 small cores. Gaming performance might suffer with a non macos system because os might not know to use bigger cores for performance intensive tasks.
Or if the bottleneck in your workflow is RAM read/write speed as opposed to RAM capacity. The RAM being on the same chip as the CPU/GPU gives it tremendously low RAM latency, which seems to be where it's getting much of its edge in these tests
The M1 has pretty high memory latency at around 100 ns [1], which is significantly higher than either AMD or Intel for typical systems. Note that physical distance between CPU and memory is rather less important for latency, as DRAM is high latency in itself, so adding a few ns at most due to wiring is not going to matter.
[1] https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...
[1] https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...
Thanks for the thorough correction.
The RAM is not on the same chip. It's regular LPDDR4X chips on the same package (connected by regular-ass PCB traces, not even a silicon interposer like HBM would've been). It's clocked pretty high, but you can go even faster on DDR4 desktops.
[deleted]
Yep. But these days for anything else, I just fire up a cloud VM and kill it when it's done. I spent less on that than the 3900X and RAM would have cost me in 5 years.
My main daily driver machine and dev box is now the absolute ass end M1 Mac Mini and it's the best computer I have ever had.
My main daily driver machine and dev box is now the absolute ass end M1 Mac Mini and it's the best computer I have ever had.
My primary dev environment is in ec2. I don't really care about multiple monitors. It's so convenient.
What do multiple monitors have to do with having a dev env on EC2?
But on a similar note, I use VS Code's Remote SSH plugin to connect to an EC2 on one monitor and terminal + browser on the other. It's not my primary dev env, but it's great for experiments and side projects.
But on a similar note, I use VS Code's Remote SSH plugin to connect to an EC2 on one monitor and terminal + browser on the other. It's not my primary dev env, but it's great for experiments and side projects.
Can you tell me more about your setup? Like which ec2 instance size, remote desktop software, and any other tips? I’ve considered doing the same.
I use different size instances, but I use SSH (mosh), tmux, and vscoder through the browser, when I "need" an IDE.
on my MacBook Air, I use azure data studio to connect to our MSSQL instances if I need a UI view of our database.
on my MacBook Air, I use azure data studio to connect to our MSSQL instances if I need a UI view of our database.
I pretty much do work that needs more then 16GB of memory all day every day (and can take advantage of CPU cores up to 12 to 16 range). But yeah very dependent on your environment/workflow.
Especially if you are just doing lightweight web dev 16GB is more then enough (could probably get away with 8GB or less)
Especially if you are just doing lightweight web dev 16GB is more then enough (could probably get away with 8GB or less)
I sit here with 24GB memory usage just from my browser, a couple PDFs and two IDEs (Visual Studio and Visual Studio Code).
Your computer always uses as much memory as possible. That’s not evidence it wouldn’t work with less.
I have 64GB memory and still occasionally get OOMs with my dev workload.
As always, it depends what you're doing.
As always, it depends what you're doing.
What are you doing?
Yeah that’s like one chrome tab running slack.
Yes, I'd really like to see a large c++ project compile added to that list of benchmarks.
Here is example of that (compilation benchmarks) for Ryzen 5950X
https://www.phoronix.com/scan.php?page=article&item=ryzen-59...
> For the code compilation speed tests were compiking Apache, PHP, the Linux kernel, ImageMagick, GDB, LLVM, FFmpeg, and MPlayer
https://www.phoronix.com/scan.php?page=article&item=ryzen-59...
> For the code compilation speed tests were compiking Apache, PHP, the Linux kernel, ImageMagick, GDB, LLVM, FFmpeg, and MPlayer
Anything trivially parallel like a large C++ scratch build is obviously going to run faster if you have many more cores even if those cores are slower. What I'd specifically like to see is a benchmark of the long pole of most builds: the single-threaded link step.
I really fear that Linux might get left behind as Apple and Microsoft go after this ARMs-race (pun intended).
At least Microsoft requires UEFI with their ARM offerings, but often the bootloaders are locked. I love Linux and I love running it natively. Currently I can grab almost any Dell, HP, Lenovo, MSI, etc. desktop/laptop and there's a very good chance all the hardware will work with mainline Linux. If I get a laptop with replaceable Wi-Fi on those little PCI-E or M.2 cards, I can pretty much get past any hardware limitations.
Microsoft pretends they're onboard with Linux, but they still have hundreds of thousands (maybe millions? I don't think they sold that well) Nokia Lumina Windows phones that are e-waste bricks. They've released no docs for people who want to make Linux drivers and people have had to find exploits to unlock their bootloaders.
PostmarketOS is making some amazing strides, but they can't keep up with all these new incompatible ARM devices. PC architecture based Intel x86/64 devices allowed for Linux to thrive in the niece hacker/developer world. ARM has no standards for basic-input-output or device management (please don't say "device tree." It's garbage and no one uses it).
Alternatively, Intel or AMD need to step up their game and show the x86_64 instruction set can be implemented in such a way to get some of the same speed boosts seen on the M1. I'm not sure which one we'll see going forward, but I hope Linux doesn't get left behind.
At least Microsoft requires UEFI with their ARM offerings, but often the bootloaders are locked. I love Linux and I love running it natively. Currently I can grab almost any Dell, HP, Lenovo, MSI, etc. desktop/laptop and there's a very good chance all the hardware will work with mainline Linux. If I get a laptop with replaceable Wi-Fi on those little PCI-E or M.2 cards, I can pretty much get past any hardware limitations.
Microsoft pretends they're onboard with Linux, but they still have hundreds of thousands (maybe millions? I don't think they sold that well) Nokia Lumina Windows phones that are e-waste bricks. They've released no docs for people who want to make Linux drivers and people have had to find exploits to unlock their bootloaders.
PostmarketOS is making some amazing strides, but they can't keep up with all these new incompatible ARM devices. PC architecture based Intel x86/64 devices allowed for Linux to thrive in the niece hacker/developer world. ARM has no standards for basic-input-output or device management (please don't say "device tree." It's garbage and no one uses it).
Alternatively, Intel or AMD need to step up their game and show the x86_64 instruction set can be implemented in such a way to get some of the same speed boosts seen on the M1. I'm not sure which one we'll see going forward, but I hope Linux doesn't get left behind.
I mean Raspberry Pi's are ARM and there are more than a few of these are running Linux(Raspian/Arch/etc/).
Linux will run on pretty much anything given an ounce of driver support. I'm not that overly worried about Linux and ARM.
Microsoft is the one that should be worried!
Linux will run on pretty much anything given an ounce of driver support. I'm not that overly worried about Linux and ARM.
Microsoft is the one that should be worried!
Yes, but each distribution has to make a custom image for each Pi. One of my favorite distros, Void Linux, only has support for the Pi 1, 2 and 3:
https://voidlinux.org/download/ (click on arm platforms)
The Pi3 image does not work on the Pi 4. There are mentions on the bug tracker and how to patch in support, but this wouldn't happen at all on a UEFI+x86 system. You'd always be able to boot to a prompt on over 90% of motherboards.
https://voidlinux.org/download/ (click on arm platforms)
The Pi3 image does not work on the Pi 4. There are mentions on the bug tracker and how to patch in support, but this wouldn't happen at all on a UEFI+x86 system. You'd always be able to boot to a prompt on over 90% of motherboards.
Very important points
We are to a point where we could be forced to trade performances for openness
We are to a point where we could be forced to trade performances for openness
Whilst I have sympathy on many of your points and understand frustration the answer cannot be neverending lock-in to the Intel/AMD duopoly.
How many x86 based netbooks are e-waste now (despite being able to run linux) because the hardware simply wasn't up to the job?
How many x86 based netbooks are e-waste now (despite being able to run linux) because the hardware simply wasn't up to the job?
Sure, they can be e-waste, but I can always pick up and old one and put Linux on it and there's a good chance I can get it working with a simple Live USB/CD, maybe some additional drivers.
The barrier to getting old ARMs to work is MUCH higher. Would a lot of them get thrown out anyway even if there was a Linux option? Most likely, but the option isn't even there.
The barrier to getting old ARMs to work is MUCH higher. Would a lot of them get thrown out anyway even if there was a Linux option? Most likely, but the option isn't even there.
Do we need to push legislation to ensure unlocked bootloaders? Or even a "click this box to void your warranty and unlock the bootloader".
> At least Microsoft requires UEFI with their ARM offerings, but often the bootloaders are locked.
AFAIK, that's not true with their ARM64 offerings.
AFAIK, that's not true with their ARM64 offerings.
The bit about multicore not being as useful for development as production is a rather odd generalization. If you build large C++/Rust/Haskell/etc projects regularly, you want all the cores.
That was my thought there are plenty of development environments where more cores are required.
The m1 is interesting but I don't think its going to scale as well as a lot of people desperately want to believe.
The m1 is interesting but I don't think its going to scale as well as a lot of people desperately want to believe.
Scaling through parallelisation is not a huge problem in CPU hardware. At worst, Apple may just "glue" a couple of M1 together and call it a day.
>Just Buy M1 if you'd like to have a low-power, long-lasting, quiet, and performant dev machine.
Well, if you are testing it for "real world programming", you should check if your development environment and all the tools you use for it works first. There is more to development than minor performance benefits from a slightly faster processor.
Do you need to run VMs for your development? How about docker? Do you compile your binaries locally?
If you deploy your code to x86_64 systems, you're most likely better off with an x86_64 machine. Even if you are developing for arm machines which are not M1 macs or iPhones or iPads, you are most likely better off with an x86_64 machine.
Well, if you are testing it for "real world programming", you should check if your development environment and all the tools you use for it works first. There is more to development than minor performance benefits from a slightly faster processor.
Do you need to run VMs for your development? How about docker? Do you compile your binaries locally?
If you deploy your code to x86_64 systems, you're most likely better off with an x86_64 machine. Even if you are developing for arm machines which are not M1 macs or iPhones or iPads, you are most likely better off with an x86_64 machine.
I wonder why the mac mini M1 seemed to sometimes underperform the macbook air M1 -- shouldn't the mac mini be outperforming the mac book air essentially across the board due to the better thermal envelope?
Maybe Apple is binning the worse chips in the Mini? It is their cheapest Mac, after all.
They bin the worse chips as a 7-core version of M1, which is not an option when configuring Mac Mini.
There should be chips where one GPU core is flawed, but the CPU cores are fine and the chip otherwise hit the correct frequencies and thermals.
Maybe there are some chips with 8 functional cores but only at lower frequencies? ... just spitballing.
I mean can you imagine the uproar it would cause if Apple did that?
There wouldn't be any uproar if they're sold as a cheaper lower spec model. Apple could be stockpiling them for later, having led with the higher performance chips for marketing purposes.
But we're not speculating about what would happen if Apple did that explicitly.
We're trying to understand why did the existing M1 Mini perform worse in some of those tests than the M1 Air did, while there is no known reason for it. Some speculate that they inexplicitly sell subpar/low freq chips, which would mean that they were selling an official 7-core, an official 8-core and a faster but otherwise non-advertised version of 8-core. And on top of that, the latter would be installed in Mac Air that has the worst (passive) cooling solution from all current M1 offerings...
That doesn't make sense on any level and is just something Apple could not do and successfully hide from everyone, especially that they already have an explicit binning process.
We're trying to understand why did the existing M1 Mini perform worse in some of those tests than the M1 Air did, while there is no known reason for it. Some speculate that they inexplicitly sell subpar/low freq chips, which would mean that they were selling an official 7-core, an official 8-core and a faster but otherwise non-advertised version of 8-core. And on top of that, the latter would be installed in Mac Air that has the worst (passive) cooling solution from all current M1 offerings...
That doesn't make sense on any level and is just something Apple could not do and successfully hide from everyone, especially that they already have an explicit binning process.
There has to be some reason for it. If not thermals, then what else about the hardware could explain the difference?
It's funny how we immediately resort to conspiracy theories about Apple and their hardware but completely forgo a substantial chance that it's the original author's human error at cause? It is much more plausible, isn't it, especially if the test results in speech actually also contradict literally every other independent test results out there?
This is why I love HN - this comment-to-comment dialogue and thought progression is always so riveting!
Especially with 8GB of RAM less!
Can't wait to see the Mac Pro.
The argument is over for best laptop processor. I want to see if Apple is as eager to beat the competition in the Workstation/HPC space as they were in the mobile/laptop.
I think they are, Srouji looks like he's got a knife in his teeth and can't wait to claim fastest personal computer ever period. But we'll have to see, it's a tiny, tiny market to justify the effort.
The argument is over for best laptop processor. I want to see if Apple is as eager to beat the competition in the Workstation/HPC space as they were in the mobile/laptop.
I think they are, Srouji looks like he's got a knife in his teeth and can't wait to claim fastest personal computer ever period. But we'll have to see, it's a tiny, tiny market to justify the effort.
The probability that Apple will target HPC is practically zero. They don’t care about low margin offerings, and HPC runs Linux which they don’t support.
Yeah, I meant workstation, I edited the comment but it was too late already.
How much effort is it really? Make a version of this with more cores and cache and maybe all high-performance cores instead of heterogenous. It's just a remix of the same already designed components.
The only really tough thing would be supporting things desktop users want like external video cards, but people may be willing to forego that if the CPU smokes everything else and if the built-in GPU is at least fast enough for serious work.
The only really tough thing would be supporting things desktop users want like external video cards, but people may be willing to forego that if the CPU smokes everything else and if the built-in GPU is at least fast enough for serious work.
> Make a version of this with more cores and cache and maybe all high-performance cores instead of heterogenous.
Just a side note. It's unlikely that Apple will eliminate their "slow" cores from their desktops. Mac Pros spend big chunks of their time doing mundane things which their efficiency cores do just fine. By using their efficiency cores, they can bring down total power requirements and their desktops can essentially run continually as opposed to entering a dedicated sleep more.
I suspect the Mac Pro will sip power and run cool as a cucumber most of the time when it's not getting hammered for high end tasks.
Just a side note. It's unlikely that Apple will eliminate their "slow" cores from their desktops. Mac Pros spend big chunks of their time doing mundane things which their efficiency cores do just fine. By using their efficiency cores, they can bring down total power requirements and their desktops can essentially run continually as opposed to entering a dedicated sleep more.
I suspect the Mac Pro will sip power and run cool as a cucumber most of the time when it's not getting hammered for high end tasks.
I don’t think it’s that simple. This design is so good because Apple designed a system, and didn’t throw together a few parts they could buy.
They should revisit all choices they made earlier. Users might want more generic ML hardware, so that they can develop the algorithms that can get burned into specific hardware on some future consumer-level hardware, a GPU that can ray trace better, more memory than you can fit on a SoC, etc.
That last issue is particularly problematic. They might have to give up the idea of having (only) unified memory.
If so, the entire design could change. In some cases, that could mean task-specific hardware isn’t (much) faster anymore than doing it in the CPU, in which case discarding it to make room for extra cores, cache, etc. might be the better choice.
They should revisit all choices they made earlier. Users might want more generic ML hardware, so that they can develop the algorithms that can get burned into specific hardware on some future consumer-level hardware, a GPU that can ray trace better, more memory than you can fit on a SoC, etc.
That last issue is particularly problematic. They might have to give up the idea of having (only) unified memory.
If so, the entire design could change. In some cases, that could mean task-specific hardware isn’t (much) faster anymore than doing it in the CPU, in which case discarding it to make room for extra cores, cache, etc. might be the better choice.
It’s a focus and vertical integration thing. Is the market big enough to justify the increased costs of SW and HW development (not just direct incremental cost but also indirect costs like more support staff, office space, etc). Then are the developments you make to support that market transferable in some way. Are there techniques you prototype in the more expensive/less power-constrained space that help your other markets in the long term?
Im sure Apple could produce something in the HPC space. The question is whether it makes financial and/or strategic sense to compete there.
Im sure Apple could produce something in the HPC space. The question is whether it makes financial and/or strategic sense to compete there.
Probably mostly this, but I would wager more work goes into providing more PCI lanes because I/O tends to be more demanding in pro workloads (connecting all kinds of things)
I'd be surprised if they didn't still include 2 or 4 high efficiency cores to continue touting power efficiency - the business customers would love to cut their power bill in the long term.
What you’re describing is the iMac, iMac Pro, Mac mini pro, etc.
But I think they’ll have the Mac Pro continue to be RAM, GPU and PCI upgradable.
How they are doing that is the most interesting secret in the industry.
But I think they’ll have the Mac Pro continue to be RAM, GPU and PCI upgradable.
How they are doing that is the most interesting secret in the industry.
There's not really any magic to it, they just need to implement PCIe and include memory slots instead of hardwired chips on the package. There are other ARM systems that already do this.
Yeah, but then you lose the benefits of the integrated memeory.
How they're gonna solve that is the big question.
How they're gonna solve that is the big question.
There actually aren't really any benefits outside of manufacturing. Trace length is a marginal factor in memory performance/latency, and having the memory on-package versus only slightly further away doesn't mean much. I'm not sure exactly where the idea that having the memory on-package was so beneficial came from, especially considering the M1 actually has fairly poor memory latency (though within the expected normal range for LPDDR4X):
https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...
As far as HSA/unified memory architecture, PCIe 4.0 has enough bandwidth to comfortably access main memory for applications that support it (and vice versa with GPU memory), although I imagine most high-performance GPU workloads will do better primarily operating on dedicated GPU memory (especially given that a single M1 core can already saturate the memory controller on its own).
https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...
As far as HSA/unified memory architecture, PCIe 4.0 has enough bandwidth to comfortably access main memory for applications that support it (and vice versa with GPU memory), although I imagine most high-performance GPU workloads will do better primarily operating on dedicated GPU memory (especially given that a single M1 core can already saturate the memory controller on its own).
This is not my area of expertise, but I’ve seen concerns of implementing the unified memory architecture off chip. But maybe it’s just that it hasn’t been done yet.
That doesn't have any impact. The memory isn't on-chip, it's just on-package. This makes it no different from if it was fully external.
This has also not been a problem for any other unified memory system (which typically also do not include memory on-package), and I can't see any reason why it would matter.
This has also not been a problem for any other unified memory system (which typically also do not include memory on-package), and I can't see any reason why it would matter.
> I want to see if Apple is as eager to beat the competition in the HPC space
Doesn't HPC use PPC or something?
I could see them delivering on Desktop, not sure about HPC though. There's only one Fortran compiler for M1!
Doesn't HPC use PPC or something?
I could see them delivering on Desktop, not sure about HPC though. There's only one Fortran compiler for M1!
> Just Buy M1 if you'd like to have a low-power, long-lasting, quiet, and performant dev machine.
I would absolutely love to buy the M1 MacBook Air (and I almost did), the performance is just too good. It’s nearly impossible to justify spending money on any other laptop. Unfortunately, I just can’t get past the single external display limitation. I did see there is a DisplayLink workaround to get multiple external displays working, but the performance of DisplayLink is not great and requires purchasing a dock.
It’s frustrating because I want to buy a M1 laptop, and the display support is a complete dealbreaker.
Assuming Apple addresses the display support in the M2 laptops, they’ll be an insta-buy for me.
I would absolutely love to buy the M1 MacBook Air (and I almost did), the performance is just too good. It’s nearly impossible to justify spending money on any other laptop. Unfortunately, I just can’t get past the single external display limitation. I did see there is a DisplayLink workaround to get multiple external displays working, but the performance of DisplayLink is not great and requires purchasing a dock.
It’s frustrating because I want to buy a M1 laptop, and the display support is a complete dealbreaker.
Assuming Apple addresses the display support in the M2 laptops, they’ll be an insta-buy for me.
This is my dealbreaker too. When at my desk, I refuse to give up my 2x 4K displays, it is just such a productivity booster. I'm not willing to do the DisplayLink hack to get it.
This seems practically certain to be addressed with the next generation; it's fairly clearly a limitation inherited from the iPad, and Apple have long made a big deal about how many monitors you could attach to their high-end MBPs.
It's got Thunderbolt 3, so maybe with an external graphics card…? Drivers might be an issue though.
Can't you configure it with two external displays (and the internal display blank)?
This compares a desktop Ryzen with macbook Intel and macbook/mac-mini M1. Thermal design of the laptops likely plays a large role in the benchmark results.
I would also point out though some interesting places where the 3900x clearly wins. Looking at Naive Bayes for example, it's a nearly 10 fold difference in speed. I wonder what specific x86 optimizations help there, likely SIMD?
Alternatively, problems with OpenJDK on ARM64. Given the limited target market for it (basically just Graviton2, which is also pretty new), I can't imagine that huge amounts of work has been put into it so far.
It also compares right out of the oven M1 with generation old Ryzen and 2 generations old Intel.
Many people overstate Apple's achievement, in reality most credit should go to TSMC the company that manufactures the M1 chip.
The M1 is a 5nm chip, while the i9 is a 14nm chip! The M1 has about 16b transistor, the i9 has only about half of that amount.
Apple's only achievement here was to make a deal with TSMC in order to be the first one to use their 5nm technology.
The M1 is a 5nm chip, while the i9 is a 14nm chip! The M1 has about 16b transistor, the i9 has only about half of that amount.
Apple's only achievement here was to make a deal with TSMC in order to be the first one to use their 5nm technology.
Did Apple not actually _design_ the chip, lay out transistor locations, do virtual testing against the future design, find bottlenecks, etc?
5nm is incredible and should not be understated; but I don't think anyone on the outside can say "most credit" should go to TSMC. A lot of credit? Absolutely. Most credit? I don't know.
5nm is incredible and should not be understated; but I don't think anyone on the outside can say "most credit" should go to TSMC. A lot of credit? Absolutely. Most credit? I don't know.
Sure, the M1 chip is very good, the question here is what made the M1 perform better than a i9 and I would argue it is because of the 5nm technology. If the M1 had only 8b transistors and was using 14nm technology I really doubt that it would beat the i9.
5nm and 14nm are marketing names, not x^2/y^2 times better statistics. If you normalize them (i.e. actually look at transistor density) you'll find the difference is much smaller than you'd expect. TSMC 5nm is indeed the better process though but it alone isn't the primary driver of what makes the M1 good. Flipping it around I'm not as sure the i9 would come out on top all other things being equal between the 2.
I'm not sure there are many engineers at Apple that truly understand what makes the M1 perform better. How people think they can just boil it down to just <x> is honestly confusing.
I'm not sure there are many engineers at Apple that truly understand what makes the M1 perform better. How people think they can just boil it down to just <x> is honestly confusing.
>I'm not sure there are many engineers at Apple that truly understand what makes the M1 perform better.
Of course there are, and those people are computer engineers or electrical engineers (and I'm sure many software folks as well, there are a lot of smart people in the world).
>How people think they can just boil it down to just <x> is honestly confusing.
I would wager you a bar tab that those people are all ill-informed developers. I am no expert in software, let alone hardware, but I am always suprised how often I see professional developers bemoan the fact that their laptop 'uses 12 gigs of ram' to run the OS + a few chrome tabs. A huge amount of devs don't know how their OS manages memory, let alone the ins and outs of the design and operation of modern microprocessors.
Of course there are, and those people are computer engineers or electrical engineers (and I'm sure many software folks as well, there are a lot of smart people in the world).
>How people think they can just boil it down to just <x> is honestly confusing.
I would wager you a bar tab that those people are all ill-informed developers. I am no expert in software, let alone hardware, but I am always suprised how often I see professional developers bemoan the fact that their laptop 'uses 12 gigs of ram' to run the OS + a few chrome tabs. A huge amount of devs don't know how their OS manages memory, let alone the ins and outs of the design and operation of modern microprocessors.
If TSMC buys its lithography machines, why should it even get any credit for 5nm at all?
Apple's only achievement...besides the actual design of the CPU, GPU, and ML accelerator that TSMC is manufacturing. Besides that what have the Romans every done for us?
Apple's M1 basically uses the architecture used for iPhone/iPad chips. Now I don't deny that the M1 is an impressive chip. But the question is would it be as good as the i9 if it would be a 14nm chip with only half of its 16b transistors?
A couple points:
1. Transistor density isn't necessarily orthogonal to node size. Intel's 10nm process has a higher transistor density than some of TSMC and Samsung's 10, 8, and 7nm processes.
2. It doesn't matter if the M1 at 10 or 14nm would beat an i9, 5nm M1's are on sale and 5nm i9's don't exist.
3. The M1 is keeping up with or beating an i9 with fewer physical cores and no use of SMT. An M1 only has 4 "performance" cores, the "efficiency" cores aren't contributing overmuch to the overall number crunching. The i9's have 8 full physical cores with SMT.
4. The M1 is a development of the A-series chips so you can compare their performance at larger node sizes to the i9, it hasn't been good news for Intel for the past few years. The A12 and A13 have been impressive and they have only 2 "performance" cores.
TSMC deserves a lot of praise for their manufacturing and process development. But the praise to go around is not zero sum, Apple deserves as much as TSMC. This is the exact same as AMD's Zen architecture being as deserving of praise for it's impressive performance over Intel's chips.
1. Transistor density isn't necessarily orthogonal to node size. Intel's 10nm process has a higher transistor density than some of TSMC and Samsung's 10, 8, and 7nm processes.
2. It doesn't matter if the M1 at 10 or 14nm would beat an i9, 5nm M1's are on sale and 5nm i9's don't exist.
3. The M1 is keeping up with or beating an i9 with fewer physical cores and no use of SMT. An M1 only has 4 "performance" cores, the "efficiency" cores aren't contributing overmuch to the overall number crunching. The i9's have 8 full physical cores with SMT.
4. The M1 is a development of the A-series chips so you can compare their performance at larger node sizes to the i9, it hasn't been good news for Intel for the past few years. The A12 and A13 have been impressive and they have only 2 "performance" cores.
TSMC deserves a lot of praise for their manufacturing and process development. But the praise to go around is not zero sum, Apple deserves as much as TSMC. This is the exact same as AMD's Zen architecture being as deserving of praise for it's impressive performance over Intel's chips.
I'm still not sure that question matters or is valid, because it isn't a 14nm chip.
To me its like comparing two car models, one that was designed and manufactured with a v8 (and no other option) vs one designed and manufactured with an inline 4 (also with no other engine option). Then asking, well what if that v8 car had only a v4, would it still be faster?
To me its like comparing two car models, one that was designed and manufactured with a v8 (and no other option) vs one designed and manufactured with an inline 4 (also with no other engine option). Then asking, well what if that v8 car had only a v4, would it still be faster?
Arm cpu core designs like cortex a78 and x1 are also designed for tsmc 5nm. But their per core performance is like 30% to 50% worse than Apple's firestorm cores. The low power a55 is worse than Apple's low power. And the mali gpu is worse than apple gpu. The circuit design and placement on to the chip is part of the equation as well.
I'm not aware of any currently-available non-Apple ARM chips on TSMC's 5nm process. Can you name some?
Kirin 9000, it has 1 Cortex A77 at 3.13GHz, 3 Cortex A77 at 2.5Ghz, Cortex A55 for efficiency. ARM Mali-G78 MP24 GPU.
> Apple's only achievement here was to make a deal with TSMC
So Microsoft could just fly to Taiwan, hand over a few billion and magically they have an M1 chip.
I wish we could all live in your delusional fantasy world because life sounds easy there.
So Microsoft could just fly to Taiwan, hand over a few billion and magically they have an M1 chip.
I wish we could all live in your delusional fantasy world because life sounds easy there.
My point here is not to deny the achievement of creating your own chip design, but rather demystify how the M1 achieves its performance, and I believe it has mainly to do with TSMC's 5nm technology and the huge number of transistors.
If you look up here https://en.wikipedia.org/wiki/Transistor_count
You'll see that the M1 is the first CPU/GPU (for computers) to use 5nm and one of the biggest by transistor count.
Considering those facts I think it is very unfair to claim that the M1 is faster only because of some Apple magic.
The Ryzen used in this test is also made by TSMC but using a 7nm process.
According to TSMC moving from 7nm to 5nm means 84% more transistors for the same chip size with a 15% speed improvement or a 30% lower power consumption.
Note that, from what leaked from peoples' NDAs, it seems like performance by the A12Z in the devkits (made on TSMC's 7nm process, half the cores, two year old core design) was also very good. 5nm will be contributing somewhere, but probably not so much.
The A12 and A13 (also 7nm) also did very well vs Qualcomm chips on the same process.
The A12 and A13 (also 7nm) also did very well vs Qualcomm chips on the same process.
The benchmarks look promising, but the advice at the end to "Just Buy M1 if you'd like to have a low-power, long-lasting, quiet, and performant dev machine" glosses over the issue of software compatibility; if you're buying an M1 device to use as a dev machine today, some of the tools you use may not yet work on M1.
Rapidly being fixed, from what I can tell from tables.
I don't think it is going to be any worse than upgrading to a newer version of OSX, where a couple programs here and there just never work again because the devs threw in the towel, while every other dev and studio does whatever they need to do to make it work.
I don't think it is going to be any worse than upgrading to a newer version of OSX, where a couple programs here and there just never work again because the devs threw in the towel, while every other dev and studio does whatever they need to do to make it work.
As soon as Apple sells this chip in a 32GB package I am going to be all over it.
Same!
I was worried about this too, but have been pleasantly surprised by this laptop. I'm sure my use case is far different to yours though. I was looking at my RAM consumption on my 16GB MacBook Pro prior to purchasing the M1 MacBook Air, and I was usually hitting 14-15GB with multiple GB of swap used in my regular use case (couple of chrome tabs, some electron apps, Xcode, 1st party apps all open).
I consciously pare down my usage on this MacBook Air, but I am typically at around 7GB/8GB of ram, with 3-4GB of swap space used. It feels noticeably snappier and overall better (minus some odd Big Sur UI bugs every now and then) than my 2017 15in MBP.
I consciously pare down my usage on this MacBook Air, but I am typically at around 7GB/8GB of ram, with 3-4GB of swap space used. It feels noticeably snappier and overall better (minus some odd Big Sur UI bugs every now and then) than my 2017 15in MBP.
I wouldn't be worried about 16GB now (my current MacBook is 16GB and I don't have any problems). But I want my laptop to least a decent amount of time (at least 5 years), and I do worry about whether 16GB will be sufficient then.
This is one of the biggest reasons for me, personally. It is such an inexpensive difference in overall cost versus the benefits of having that headroom.
Plus I am sitting at ~26gb used memory right now. I tend to give my VM's a nice big 8-12GB chunk of ram depending on what I am doing too, so it is almost like I have two machines in one.
The disks and data pipelines on these new machines are so fast though that I do wonder if the RAM's responsibility has shifted towards being a giant CPU cache and the disk has likewise shifted into a point where it performs more like RAM.
Plus I am sitting at ~26gb used memory right now. I tend to give my VM's a nice big 8-12GB chunk of ram depending on what I am doing too, so it is almost like I have two machines in one.
The disks and data pipelines on these new machines are so fast though that I do wonder if the RAM's responsibility has shifted towards being a giant CPU cache and the disk has likewise shifted into a point where it performs more like RAM.
Maybe that’s the eventuality. I don’t run VMs much if at all for my work/day to day, but I have a desktop in the event I need to.
It depends on what you do, and always will. 16GB will be enough for web browsing, gaming, and coding websites in python 5 years down the line. 16GB is not enough now for.. say, compiling Firefox with LTO, at least while browsing.
I figure I will eventually pass this laptop on to a family member by the time I will be in the market for a new laptop, so I am not necessarily worried about that. I suspect my 2017 mbp would have worked fine for a few more years but I wanted to transition to a more portable device.
One nice aspect of Big Sur and the M1 is that you can run the iPad version of many apps, rather than the Electron desktop version. The iPad versions often use way less memory.
I wonder if the Mac Pro version of this will do a two-tiered thing, with 16GB on the chip, and then a bunch of slots for your slower, "external" memory modules— basically the Mac Fusion Drive of RAM, with an internal controller to manage moving stuff in and out of the low-latency area.
I could certainly also see them going all-in on the integrated architecture, but the possibilities are intriguing if they want a reasonable story for a workstation that goes up to 100s of GB (the current Mac Pro's top configuration is an eye-watering 1.5TB of RAM).
I could certainly also see them going all-in on the integrated architecture, but the possibilities are intriguing if they want a reasonable story for a workstation that goes up to 100s of GB (the current Mac Pro's top configuration is an eye-watering 1.5TB of RAM).
There's not really any reason it would be slower. Being on-package doesn't offer any real performance advantage (the lengths of the traces to memory have a negligible impact on performance or latency), and is more of a benefit to manufacturing.
The memory on the M1 actually has fairly poor latency compared to most x86 systems:
https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...
The memory on the M1 actually has fairly poor latency compared to most x86 systems:
https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...
The on-package RAM is probably more aimed at reducing power consumption; it's not particularly low-latency. This obviously wouldn't be an issue for an MBP.
Has to be a new chip, this one is limited to 36bit address space. We won’t see a 32GB M1
Why is the naive-bayes benchmark (first graph) such an extreme outlier? M1 is ~10 times slower on this benchmark whereas it is faster than the competition on almost any other benchmarks.
The decoupling of the class conditional feature distributions of the naive-bayes benchmark means that each distribution can be independently estimated as a one-dimensional distribution.
This helps alleviate problems stemming from the curse of dimensionality, such as the need for data sets that scale exponentially with the number of features. This is precisely an area where x86 architecture and CISC ISA will out rank the RISC-V ISA of M1's.
But perhaps, I don't know what I am talking about. Someone with more knowledge, please chime in.
[1] https://web.archive.org/web/20140311005243/http://machinelea...
[2] https://www.researchgate.net/publication/228845263_An_Empiri...
This helps alleviate problems stemming from the curse of dimensionality, such as the need for data sets that scale exponentially with the number of features. This is precisely an area where x86 architecture and CISC ISA will out rank the RISC-V ISA of M1's.
But perhaps, I don't know what I am talking about. Someone with more knowledge, please chime in.
[1] https://web.archive.org/web/20140311005243/http://machinelea...
[2] https://www.researchgate.net/publication/228845263_An_Empiri...
M1 is not RISC-V and I don't think CISC vs RISC is of any significance here.
If naive bayes is really embarassingly parallel, SIMD+lots of cores help here of course. It is also probably highly optimized code that doesn't rely so significantly on OoO capabilities and can take advantage of the higher clock rate.
Even Itanium was very good at numerical code.
If naive bayes is really embarassingly parallel, SIMD+lots of cores help here of course. It is also probably highly optimized code that doesn't rely so significantly on OoO capabilities and can take advantage of the higher clock rate.
Even Itanium was very good at numerical code.
What is the M1 then?
https://medium.com/swlh/what-does-risc-and-cisc-mean-in-2020...
confused.
https://medium.com/swlh/what-does-risc-and-cisc-mean-in-2020...
confused.
[deleted]
Yeah, nice. Need 64 Gb and some way to virtualize x64 operating systems though. Not everyone does web development.
I could do a good part of my work on a M1 but not with so little ram. Come to think of it, did Apple limit the first ARM Macs to 16 Gb to specifically keep people like me away from it until the software matures a bit?
I could do a good part of my work on a M1 but not with so little ram. Come to think of it, did Apple limit the first ARM Macs to 16 Gb to specifically keep people like me away from it until the software matures a bit?
The colors on those bar charts makes everything so much harder to interpret than it needs to be. The two M1 bars should have similar (but distinguishable colors). The two Intel bars should have similar, but distinguishable colors (they are the same!). They should all have similar luminance contrast with the background. Charts that use bars to represent things other than those categories should use different colors than the other bars (the blue and red are reused in the Go chart). The colors used for a given category should be consistent across all the charts (different colors are used when you get to the Redis test).
FYI: Comparing current generation M1 to old generation AMD and Intel. Mix of laptop and desktop.
I'm not a hardware review expert but I think one of the biggest advantages of the Ryzen 5000 series vs the 3900x is the CPU performance for apps that don't take advantage of parallelism across many cores. The 5000 series has a completely new architecture and is supposedly WAY faster than the 3000 series for single core tasks. That's partly why gaming performance is so much better with the 5000 series since it often comes down to execution speed on 1 core, but that would also apply to many programming benchmarks too.
It would be interesting to see the same benchmarks with the 5000 series. I know the author said he didn't have that CPU to test it against, but IMO it would be a more fair comparison considering the 3900x is using an older CPU architecture that has been drastically improved upon with hardware that's available today (ie. the 5000 series isn't the next gen, it's the current gen).
It would be interesting to see the same benchmarks with the 5000 series. I know the author said he didn't have that CPU to test it against, but IMO it would be a more fair comparison considering the 3900x is using an older CPU architecture that has been drastically improved upon with hardware that's available today (ie. the 5000 series isn't the next gen, it's the current gen).
> with hardware that's available today
I'm not sure the 5900x or 5950x qualify as "available today". Orderable today for delivery in 2-3 months, maybe.
That said, I do agree, the 5900x looks to be about 15-20% faster on single/few core tasks than the 3900x from benchmarks I've seen.
Also worth mentioning is that the M1 is one process node head of the 3900x/5900x (TSMC 5nm vs TSMC 7nm). There's a much slower rate of process shrinks these days, so I'd imagine 5nm will be available to AMD before Apple jumps to the next node.
I'm not sure the 5900x or 5950x qualify as "available today". Orderable today for delivery in 2-3 months, maybe.
That said, I do agree, the 5900x looks to be about 15-20% faster on single/few core tasks than the 3900x from benchmarks I've seen.
Also worth mentioning is that the M1 is one process node head of the 3900x/5900x (TSMC 5nm vs TSMC 7nm). There's a much slower rate of process shrinks these days, so I'd imagine 5nm will be available to AMD before Apple jumps to the next node.
> I'm not sure the 5900x or 5950x qualify as "available today". Orderable today for delivery in 2-3 months, maybe.
Yeah the supply is low but I mean it's the current generation of chip that was released a few months before M1. It seems reasonable to compare the current gen vs the current gen instead of the current gen (M1) vs the previous gen (AMD 3000 series).
Hopefully the demand slows down in the next few months. I'm thinking about upgrading my workstation and I'm going AMD this time around (I've used Intel CPUs since the Pentium II era).
Yeah the supply is low but I mean it's the current generation of chip that was released a few months before M1. It seems reasonable to compare the current gen vs the current gen instead of the current gen (M1) vs the previous gen (AMD 3000 series).
Hopefully the demand slows down in the next few months. I'm thinking about upgrading my workstation and I'm going AMD this time around (I've used Intel CPUs since the Pentium II era).
Eh, comparing what people can buy today makes sense. Especially if the comparer doesn't even have access to the theoretically launched but unavailable part.
I quickly looked up the AMD for price and TPD. Turns out, AMD Ryzen 3900X is a 105W TPD CPU with 420GBP price tag when on discount. The base Mac mini is 699GBP.
Is there any info on the overclock prospects for Apple M1? Is there possibility to run this beast at AMD&Intel heat output levels? How fast a water cooled M1 could be?
Is there any info on the overclock prospects for Apple M1? Is there possibility to run this beast at AMD&Intel heat output levels? How fast a water cooled M1 could be?
M1 doesn't hit thermal dissipation capacity of Apple's fan solutions (in Mini and MB Pro). You can witness that by torturing the CPU and not even hearing the fan at all. Plenty f videos on the web show that. The fan spins, but only barely and never quite as much as with Intel I-series. And they use the same fan/heatpipe as with previous models, so nothing was improved here.
I've been using my M1 MBP for a few days now, and the only way I have been able to get the fan to even power on was to run Cinebench.
This morning I was basically running the entire MS office suite, joined a video meeting, had a couple dozen tabs open in my browser, a couple of nodejs apps, and a few other things -- and the fan still didn't start.
This morning I was basically running the entire MS office suite, joined a video meeting, had a couple dozen tabs open in my browser, a couple of nodejs apps, and a few other things -- and the fan still didn't start.
Really crazy results imo, being able to carry around the performance of a desktop in a laptop is quite the feat. I might pick up a MacBook next year if they allow for more than only 1 external display connected and increase to 4 usb c ports. Seems like a powerful portable option.
I don’t understand the 4 ports issue. If you have that many things to plug in at your desk, don’t you keep them plugged into a dock that has power delivery, and just connect one wire when you sit down?
To be honest now that you say that it sounds less of an issue than I think but I still feel a little strangled by only two ports for some reason.
I am all for more attempts to benchmark programming tasks. I really appreciate this article for that, and I hope we see more content like this.
However, I would note a couple of things:
- As the author acknowledges, the Ryzen CPU is last gen. The current generation of Ryzen CPUs are about 20% faster gen-over-gen.
- The memory configuration used with that Ryzen CPU is not optimal. I believe DDR4-3600 is recommended, and does have a measurable impact on performance.
That said, the M1 is still quite impressive. However the Ryzen 5 5600X (or the upcoming Ryzen 7 5800U for laptops) is a solid choice for a developer workstation.
EDIT: I would also add, the limitation of 16GB RAM max is a deal breaker for me (as MacOS, but that's a different story).
However, I would note a couple of things:
- As the author acknowledges, the Ryzen CPU is last gen. The current generation of Ryzen CPUs are about 20% faster gen-over-gen.
- The memory configuration used with that Ryzen CPU is not optimal. I believe DDR4-3600 is recommended, and does have a measurable impact on performance.
That said, the M1 is still quite impressive. However the Ryzen 5 5600X (or the upcoming Ryzen 7 5800U for laptops) is a solid choice for a developer workstation.
EDIT: I would also add, the limitation of 16GB RAM max is a deal breaker for me (as MacOS, but that's a different story).
There were a few confusing bits to this article including the fact that the preamble shows different specs than the graphs and tables in the actual benchmarks. There is also mismatched labels on the axes sometimes they are per machine and sometimes they are per benchmark which made it a little hard to follow. The overall point that the M1 is a viable development machine is really nice to see. I am intrigued by the fact that the air seems to be the mini often times—I would be interested to know more about why. I would also be interested to see additional benchmarks from other lower level languages like rust, C and Swift.
Super impressive, but these are all single threaded workloads, right?
Shouldn't Ryzen 4000 be a better comparison?
Agree, but comparing a desktop class processor that was released 1.5yrs ago that at minimum was taking 100W or more to compute is still very eye-opening in seeing how far processor technology has come in such a short time.
Ryzen 4000 is a mobile processor. Ryzen 5000 would likely fare better, but it is hard to acquire right now. Even then, it will be a process node behind the M1 (TSMC 7nm vs 5nm) so I suspect the battle for the fastest core will be heating up into next year.
edit: ah, I suppose the M1 is also a mobile processor. Having one myself (in the form of a Mac Mini,) it’s easy to forget...
edit: ah, I suppose the M1 is also a mobile processor. Having one myself (in the form of a Mac Mini,) it’s easy to forget...
Not necessarily mobile, 4750G is an 8-core desktop APU (especially famous in the overclocking crowd for having the best DDR4 memory controller ever, thanks to being a monolithic TSMC 7nm die).
In the article:
> You may wonder why I used 3900X instead of Ryzen 5000-series CPUs: Because I don't have it.
Ryzen 4000 series (which is for laptops) is relatively easy to get, but I don't fault the author for not buying a laptop specifically for this benchmark. The 3900x still pulls more power and is on the same technology as the 4900HS/4900H so it's definitely not a bad-faith comparison.
Not exactly. The 4000 series part have a finer lithography for I/O and use a low power process.
Isn't it much the case that AMD beats Intel because AMD is 7nm while Intel is 10nm. And now, Apple is 5nm. You would expect the fastest performance from 5nm, assuming we don't take into account multi-threading.
https://www.tomshardware.com/news/Apple-M1-Chip-Everything-W...
https://www.tomshardware.com/news/Apple-M1-Chip-Everything-W...
Intel isn't really "on 10nm". The economics of the 10nm process are terrible, yields are still so poor that it is basically only usable for low-power, low-core-count mobile chips, produced in low quantities.
Seems like the major win for this chip is having Memory so close to the CPU - on the same chip.
This would also be a massive win for cloud computing too, does Amazon/Azure/GCP have anything in the works for introducing ARM chips with Memory on the same chip?
This would also be a massive win for cloud computing too, does Amazon/Azure/GCP have anything in the works for introducing ARM chips with Memory on the same chip?
I am very excited to see what the M1X and other higher power variants is like.
I have an M1 MBA with the 7-core GPU, and it is a stunning machine. It is fast in everything, and in ways that Intel and AMD laptops are not. Every single interaction is fast. You will shave seconds off of everything, and it adds up over the course of a day.
The other big thing is the battery life. I do not use this laptop plugged in. I tend to charge it overnight, and it lasts through my entire day and night.
But this is of course Apple's lowest power chip, and it is plenty fast. What does a chip from Apple look like that has a lot more thermal headroom?
I have an M1 MBA with the 7-core GPU, and it is a stunning machine. It is fast in everything, and in ways that Intel and AMD laptops are not. Every single interaction is fast. You will shave seconds off of everything, and it adds up over the course of a day.
The other big thing is the battery life. I do not use this laptop plugged in. I tend to charge it overnight, and it lasts through my entire day and night.
But this is of course Apple's lowest power chip, and it is plenty fast. What does a chip from Apple look like that has a lot more thermal headroom?
I recently ordered a Lenovo X1 Carbon at a steep discount ($830 for Gen 8 w/ 16 GB RAM and 512 GB SSD). I felt great about it when I ordered it, but now I'm agonizing over whether to cancel and get an M1 MacBook Air instead. I'll probably be using the laptop for 4-5 years, and I'm concerned that anything with a current-gen Intel chip is going to feel like "legacy tech" for most of that time.
Amazing how the M1 has changed the landscape. If the MacBook Air could handle 2 external displays, I probably wouldn't even hesitate.
Amazing how the M1 has changed the landscape. If the MacBook Air could handle 2 external displays, I probably wouldn't even hesitate.
I own a Carbon X1 and it's one of my favorite laptops ever. I work exclusively on Linux, and detest Apple and the Walled Garden strategy in all their consumer products. That strategy is ridiculous for developer-related product, and I dislike that MacOS is hard to customize compared to Linux.
I would still cancel and order an M1 instead. It's that impressive of an upgrade.
I would still cancel and order an M1 instead. It's that impressive of an upgrade.
Yeah, I feel the same. I'm about to buy a Thinkpad T14 AMD Pro 4750U and I know that the M1 is superior, but in the end I've never been interested in Apple gear, and I don't feel like changing that viewpoint now. I'm waving the white flag, but I'm not crossing sides.
Hopefully we'll start seeing Intel / AMD chips that can compete with the M1. Otherwise, I might buy an M1 laptop and run Linux on it.
My workstation will still be Linux, however for a laptop, the new Macbook Air is the new favorite.
As much as I detest Apple's business strategies, this is a remarkable achievement for them. Never thought I'd buy another Apple laptop.
My workstation will still be Linux, however for a laptop, the new Macbook Air is the new favorite.
As much as I detest Apple's business strategies, this is a remarkable achievement for them. Never thought I'd buy another Apple laptop.
Same. I was about to order a X1, then the new Apple machines hit and switched to an M1 Air. Just the battery life itself is a good enough reason.
I say that as someone who has been very critical of Apple for the last 5 years too. Looks like they care about their laptops again.
I say that as someone who has been very critical of Apple for the last 5 years too. Looks like they care about their laptops again.
Linux works great on X1 Carbons, not so much on new Apple machines. Keep the X1 if you care about that.
Also the next gen Carbons are supposed to have a 16:10 screen.
Also the next gen Carbons are supposed to have a 16:10 screen.
I actually prefer Windows w/ WSL2 on my laptops rather than a bare-metal Linux install. It adds a bit of friction, but in return I never have any issue with external displays, sleep/wake, OS upgrades, etc.
> Also the next gen Carbons are supposed to have a 16:10 screen.
Yeah, a taller screen and Tiger Lake processors will probably be a significant improvement. However, I think they'll probably sell for close to "list price" when they are released (so $1500+ for a decent configuration). The build quality is a bargain at $830, not so much at $1500.
> Also the next gen Carbons are supposed to have a 16:10 screen.
Yeah, a taller screen and Tiger Lake processors will probably be a significant improvement. However, I think they'll probably sell for close to "list price" when they are released (so $1500+ for a decent configuration). The build quality is a bargain at $830, not so much at $1500.
$830 is a great deal at those specs.
I thought about the X1 Carbon, but the aspect ratio was a turn off for me. Even though it is 14 inch, somehow, I feel I get more usable space with Macs. I am waiting for the 14 inch though since I also plan to keep it for 4-5 years.
Wow how did you get it that cheap?
At that price I wouldn’t worry about it becoming obsolete I would just wait 2-3 years for either another round of Mac updates or a Thinkpad with more modern chip
At that price I wouldn’t worry about it becoming obsolete I would just wait 2-3 years for either another round of Mac updates or a Thinkpad with more modern chip
Public price was $999[1], which stacked with a discount available through my employer.
I suspect they're trying to clear stock of the Gen 8, which faces tough competition from the M1 MacBook Air, the new Dell XPS 13 (with 11th gen Tiger Lake chips), and the upcoming X1 Carbon Gen 9 (also presumably with Tiger Lake chips).
[1] https://www.lenovo.com/us/en/laptops/thinkpad/thinkpad-x1/X1..., specific model I ordered is "Temporarily Unavailable" on the far right.
I suspect they're trying to clear stock of the Gen 8, which faces tough competition from the M1 MacBook Air, the new Dell XPS 13 (with 11th gen Tiger Lake chips), and the upcoming X1 Carbon Gen 9 (also presumably with Tiger Lake chips).
[1] https://www.lenovo.com/us/en/laptops/thinkpad/thinkpad-x1/X1..., specific model I ordered is "Temporarily Unavailable" on the far right.
You can use display link adapters if necessary, or get a super ultra wide. My air is pushing 5120x1440 @ 120hz on my 49 inch super ultrawide and doesn't stress at all.
I would say your opportunity cost is higher w the Mac but really I would just want 2 laptops in 3 years
Considering that Apple won't sell their chips to anybody else, and the M2, M3, Mn could be increasingly faster than the x86 chips, how long before we start moving along this path?
1. Amazon, Google, Microsoft start building their own chips for their own clouds. The most efficient chip could translate into the cheapest cloud, or the fastest one at the same price. Their choice.
2. There will be N somewhat compatible ARM chips, that is to say they are somewhat incompatible. Remember the home computing landscape of the 80s / early 90s but also the diversity in server architectures and OSes.
3. At least Microsoft is likely to sell their chips to third parties (they used to sell their software). Probably Amazon and Google have reasons to sell their chips too (Google -> Chromebooks)
4. Some of those chips will end up in development laptops and desktops.
5. If you want to develop for AWS you'll be safer to have a laptop with an Amazon chip, if you want to develop for Google Cloud a Google Chip, for Azure a Microsoft chip. This is not unheard of because if you want to develop for iOS you must have Apple hardware since 10+ years ago.
6. The chip manufacturer that wins the war for the developers' machines wins the war for the cloud, because it won't be possible for (let's say) Google to compete with (let's say) Amazon if Google has to buy chips from Amazon because 90% of the developers have a laptop with an Amazon chip.
Or we'll end up with 5 different laptops (unlikely) or one that connects to a remote desktop running in the appropriate cloud with the correct chip. That laptop could be a Mac or anything else, something powerful or a thin client.
So: fragmentation and then remote desktops? Back to mainframe / time sharing?
1. Amazon, Google, Microsoft start building their own chips for their own clouds. The most efficient chip could translate into the cheapest cloud, or the fastest one at the same price. Their choice.
2. There will be N somewhat compatible ARM chips, that is to say they are somewhat incompatible. Remember the home computing landscape of the 80s / early 90s but also the diversity in server architectures and OSes.
3. At least Microsoft is likely to sell their chips to third parties (they used to sell their software). Probably Amazon and Google have reasons to sell their chips too (Google -> Chromebooks)
4. Some of those chips will end up in development laptops and desktops.
5. If you want to develop for AWS you'll be safer to have a laptop with an Amazon chip, if you want to develop for Google Cloud a Google Chip, for Azure a Microsoft chip. This is not unheard of because if you want to develop for iOS you must have Apple hardware since 10+ years ago.
6. The chip manufacturer that wins the war for the developers' machines wins the war for the cloud, because it won't be possible for (let's say) Google to compete with (let's say) Amazon if Google has to buy chips from Amazon because 90% of the developers have a laptop with an Amazon chip.
Or we'll end up with 5 different laptops (unlikely) or one that connects to a remote desktop running in the appropriate cloud with the correct chip. That laptop could be a Mac or anything else, something powerful or a thin client.
So: fragmentation and then remote desktops? Back to mainframe / time sharing?
What utter nonsense. Different ARM chips aren't "somewhat compatible" anymore than Intel/AMD x86 chips. It's a standard instruction set. And even if we'd get different instruction sets, we have much better toolchains/compilers to work with multiple architectures now than we did in "the home computing landscape of the 80s / early 90s" (GCC and LLVM aren't really comparable to Sinclair Basic).
The M1 has been out for a month and we already have hundreds/thousands of natively compiled binaries—and Windows and Linux are up and running.
Choice is not a problem and competition is good.
The M1 has been out for a month and we already have hundreds/thousands of natively compiled binaries—and Windows and Linux are up and running.
Choice is not a problem and competition is good.
>Different ARM chips aren't "somewhat compatible" anymore than Intel/AMD x86 chips. It's a standard instruction set.
Can you create a single build for all ARM chips for the same OS? If not, its all the same. At work we're using binaries built for XP that work without modification on W10. No doubt, its a testament to the massive backwards compat. effort by MS, but also from Intel. This is a massive, massive benefit to actual customers who just want to keep running software that they purchased/developed/commissioned on the replacement hardware when their current hardware fails. ARM/M1 brings a lot of benefits too, but as always, each person has to decide what they're willing to give up.
>The M1 has been out for a month and we already have hundreds/thousands of natively compiled binaries—and Windows and Linux are up and running.
Assuming the vendor is still in business, you have to rely on the good faith of the vendor to gift you the new version for free.
The OP raises very valid points, I don't know what is 'utter nonsense' about it. It's only tech, not a tribal war :)
Can you create a single build for all ARM chips for the same OS? If not, its all the same. At work we're using binaries built for XP that work without modification on W10. No doubt, its a testament to the massive backwards compat. effort by MS, but also from Intel. This is a massive, massive benefit to actual customers who just want to keep running software that they purchased/developed/commissioned on the replacement hardware when their current hardware fails. ARM/M1 brings a lot of benefits too, but as always, each person has to decide what they're willing to give up.
>The M1 has been out for a month and we already have hundreds/thousands of natively compiled binaries—and Windows and Linux are up and running.
Assuming the vendor is still in business, you have to rely on the good faith of the vendor to gift you the new version for free.
The OP raises very valid points, I don't know what is 'utter nonsense' about it. It's only tech, not a tribal war :)
Linux is up and running? Maybe one should get a Macbook air then
> And even if we'd get different instruction sets, we have much better toolchains/compilers to work with multiple architectures now than we did in "the home computing landscape of the 80s / early 90s" (GCC and LLVM aren't really comparable to Sinclair Basic).
I would add that mac osx does have universal binaries for some years.
https://en.wikipedia.org/wiki/Universal_binary
I would add that mac osx does have universal binaries for some years.
https://en.wikipedia.org/wiki/Universal_binary
I thought the m1 has dedicated js instructions.
There are several theories as to why the M1 does so well on on JavaScript benchmarks.
>Firestorm can do 4 FADDs and 4 FMULs per cycle with respectively 3 and 4 cycles latency. That’s quadruple the per-cycle throughput of Intel CPUs and previous AMD CPUs, and still double that of the recent Zen3, of course, still running at lower frequency. This might be one reason why Apples does so well in browser benchmarks (JavaScript numbers are floating-point doubles).
https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...
>Apple has confirmed that it’s a massive 192KB instruction cache. That’s absolutely enormous and is 3x larger than the competing Arm designs, and 6x larger than current x86 designs, which yet again might explain why Apple does extremely well in very high instruction pressure workloads, such as the popular JavaScript benchmarks.
https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...
>Firestorm can do 4 FADDs and 4 FMULs per cycle with respectively 3 and 4 cycles latency. That’s quadruple the per-cycle throughput of Intel CPUs and previous AMD CPUs, and still double that of the recent Zen3, of course, still running at lower frequency. This might be one reason why Apples does so well in browser benchmarks (JavaScript numbers are floating-point doubles).
https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...
>Apple has confirmed that it’s a massive 192KB instruction cache. That’s absolutely enormous and is 3x larger than the competing Arm designs, and 6x larger than current x86 designs, which yet again might explain why Apple does extremely well in very high instruction pressure workloads, such as the popular JavaScript benchmarks.
https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...
> "There are several theories as to why the M1 does so well on on JavaScript benchmarks."
A major reason it does so well is the native Javascript support added in ARMv8.3-A.
Specifically, FJCVTZS (Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero)[1] which is a Javascript-specific variant of FCVTZS implementing the overflow and exception handling behaviour that Javascript wants.
Javascript needs to do these conversions a lot, since it doesn't have integer types, and it's much faster to have it implemented in silicon rather than using the old instructions and having to handle the overflow/error checking.
[1] https://developer.arm.com/documentation/100076/0100/a64-inst...
A major reason it does so well is the native Javascript support added in ARMv8.3-A.
Specifically, FJCVTZS (Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero)[1] which is a Javascript-specific variant of FCVTZS implementing the overflow and exception handling behaviour that Javascript wants.
Javascript needs to do these conversions a lot, since it doesn't have integer types, and it's much faster to have it implemented in silicon rather than using the old instructions and having to handle the overflow/error checking.
[1] https://developer.arm.com/documentation/100076/0100/a64-inst...
People who were looking for a root cause of the iOS JavaScript performance advantage have been pointing to that instruction as "the" reason before it was even used by Safari.
https://mobile.twitter.com/saambarati/status/104920213252247...
I'm sure it doesn't hurt, but the performance advantage predates the instruction's use.
Here's another theory.
>Finally doing perf counters on a dedicated test bench... 9900K having 60% worse branch misprediction than Apple's A12.
https://twitter.com/andreif7/status/1307420010177007625
https://mobile.twitter.com/saambarati/status/104920213252247...
I'm sure it doesn't hurt, but the performance advantage predates the instruction's use.
Here's another theory.
>Finally doing perf counters on a dedicated test bench... 9900K having 60% worse branch misprediction than Apple's A12.
https://twitter.com/andreif7/status/1307420010177007625
the second theory seems better in my experience. I pulled a few js benchmarks and ran on native Safari on m1 vs rosetta2 node and the rosetta2+node is significantly faster, suggested the instruction set is not the key.
As far as I understand that instruction is needed to get x86 FP semantics on ARM. I.e it doesn't make JS faster but just not as slow as it would otherwise be.
Also apparently most JS engines do not actually use the FP unit but can do most computations on the integer units (unless is really FP math) which normally have much lower latency (but also lower bandwidth).
Also apparently most JS engines do not actually use the FP unit but can do most computations on the integer units (unless is really FP math) which normally have much lower latency (but also lower bandwidth).
I've been thinking about the instruction cache of the M1 lately.
Another difference between x86 and ARM is that, for historical reasons, on x86 there is no need to invalidate the instruction cache explicitly when writing instructions to memory. That is, on x86, when a core writes to memory, the corresponding line in the instruction cache has to be invalidated. Since the instruction cache is usually VIPT for performance reasons, it has to be indexed only by bits which don't change in the virtual to physical mapping, otherwise there's a risk of cache aliases. For an instruction cache, an alias should not be a problem (it just wastes space with duplicated data), except that all aliases have to be flushed when invalidating by physical address.
IIRC, in 64-bit ARM user space (EL0) the only available instruction to invalidate the instruction cache is an "invalidate by virtual address" instruction. Since calling that instruction (after calling an instruction to flush the data cache to the point of unification) is required on ARM, there's no need to be able to invalidate all aliases of a physical address, like would be required on x86. That means it would be easier on ARM to have much larger instruction caches than on x86.
Another difference between x86 and ARM is that, for historical reasons, on x86 there is no need to invalidate the instruction cache explicitly when writing instructions to memory. That is, on x86, when a core writes to memory, the corresponding line in the instruction cache has to be invalidated. Since the instruction cache is usually VIPT for performance reasons, it has to be indexed only by bits which don't change in the virtual to physical mapping, otherwise there's a risk of cache aliases. For an instruction cache, an alias should not be a problem (it just wastes space with duplicated data), except that all aliases have to be flushed when invalidating by physical address.
IIRC, in 64-bit ARM user space (EL0) the only available instruction to invalidate the instruction cache is an "invalidate by virtual address" instruction. Since calling that instruction (after calling an instruction to flush the data cache to the point of unification) is required on ARM, there's no need to be able to invalidate all aliases of a physical address, like would be required on x86. That means it would be easier on ARM to have much larger instruction caches than on x86.
Where'd you get that from?
The m1 _does_ have one weird non-ARM extension; it can adopt an x86 memory model on demand.
The m1 _does_ have one weird non-ARM extension; it can adopt an x86 memory model on demand.
It's got better/more floating point capacity, which makes it faster at JS because all the numbers in JS are floating point number.
Which are part of arm ISA
What are js instructions and what does javascript(?) have to do with ISA?
IIRC, the standard ARM instruction set does include some instructions with "javascript" in the end. I think they're floating point instructions that handle some edge case (NaNs?) in the same way that x86, and therefore the JS spec, do.
See here:
https://developer.arm.com/documentation/dui0801/g/A64-Floati...
Not Apple Silicon specific though
https://developer.arm.com/documentation/dui0801/g/A64-Floati...
Not Apple Silicon specific though
This raises so many questions for me that are predicated on this being the case, but this is way out of my league so I could be off the mark. Incoming geeking about Universal Programming Languages.
1. If you can increase the performance of a language by adding language specific instruction sets to the processor, how much of a boost would we see on average?
2. Instead of building in instructions for say Python, C#, Java, etc, what if you built it in a language designed to create other languages I.E Racket? (I like Racket but another language that specialized in this would be fine). Since languages built on Racket ultimately compile to valid Racket code, you'll still get the speed up, and can program with the features and syntax you want (within reason obv constrained by the limitations of the base language).
3. I wasn't around for this, but isn't this what made Lisp faster on Lisp Machines? Since they had dedicated hardware for interpreting Lisp instructions?
1. If you can increase the performance of a language by adding language specific instruction sets to the processor, how much of a boost would we see on average?
2. Instead of building in instructions for say Python, C#, Java, etc, what if you built it in a language designed to create other languages I.E Racket? (I like Racket but another language that specialized in this would be fine). Since languages built on Racket ultimately compile to valid Racket code, you'll still get the speed up, and can program with the features and syntax you want (within reason obv constrained by the limitations of the base language).
3. I wasn't around for this, but isn't this what made Lisp faster on Lisp Machines? Since they had dedicated hardware for interpreting Lisp instructions?
You can certainly speed up a dynamic language by building VM which is a more or less ideal translation target for that language, and then implementing that VM in real hardware.
Hardware can parallelize type checks. For instance, you can have an add instruction which proceeds on the assumption that the two arguments are numbers. In parallel, a type checking unit in the hardware can abort that instruction and cause a branch to some handler if the operand types are wrong.
Function calls in dynamic languages can be expensive partly due to the dynamic checking that there are not too few or too many arguments. This affects code that doesn't otherwise require type checking (like logic that is doing nothing more than just passing arguments through several layers of functions and capturing return values). Hardware can help here also.
The industry moved toward general-purpose hardware. The Lisp people figured out ways to compile Lisp well to general-purpose hardware.
The thing about hardware is that it also needs optimization: a machine designed for ideal execution of Lisp is going to be expected to produce new revisions that are faster and faster, keeping up with advances in general-purpose machines. If it fails to do so, its performance will be overtaken by Lisp that is compiled to the general-purpose machines.
Hardware can parallelize type checks. For instance, you can have an add instruction which proceeds on the assumption that the two arguments are numbers. In parallel, a type checking unit in the hardware can abort that instruction and cause a branch to some handler if the operand types are wrong.
Function calls in dynamic languages can be expensive partly due to the dynamic checking that there are not too few or too many arguments. This affects code that doesn't otherwise require type checking (like logic that is doing nothing more than just passing arguments through several layers of functions and capturing return values). Hardware can help here also.
The industry moved toward general-purpose hardware. The Lisp people figured out ways to compile Lisp well to general-purpose hardware.
The thing about hardware is that it also needs optimization: a machine designed for ideal execution of Lisp is going to be expected to produce new revisions that are faster and faster, keeping up with advances in general-purpose machines. If it fails to do so, its performance will be overtaken by Lisp that is compiled to the general-purpose machines.
A PC = x86_64 + UEFI. They are have a lot of standard components. You can take any Linux boot USB and boot almost any PC with it and at least get a console if nothing else.
A PlayStation 4 is x86_64 but is NOT a PC. Watch the Fail0ver video on their PS4 kernel port to understand how different it is.
ARM is a god damn clusterfuck of random pins soldered to random shit and every Android kernel patched to hell in non-upstreamable ways. Look at all the work PostmarketOS has to do in order to get mainline Linux to work on all the random ARM e-waste out there.
DeviceTree is a joke. Microsoft at least forces ARM+UEFI, but they have locked bootloaders and even though people have found exploits to unlock them, there's virtually no reversed engineered drivers. All those hundreds of thousands of Lumina phones? Now they're e-waste. Worthless.
Linux grew because IBM created the PC. Compaq reversed engineered the BIOS and everyone started making compatibles. Over time, BIOS and later UEFI became solid standards.
ARM may be fast, but the non-standard Basic Input/Output and device detection makes it nothing but potential e-waste.
A PlayStation 4 is x86_64 but is NOT a PC. Watch the Fail0ver video on their PS4 kernel port to understand how different it is.
ARM is a god damn clusterfuck of random pins soldered to random shit and every Android kernel patched to hell in non-upstreamable ways. Look at all the work PostmarketOS has to do in order to get mainline Linux to work on all the random ARM e-waste out there.
DeviceTree is a joke. Microsoft at least forces ARM+UEFI, but they have locked bootloaders and even though people have found exploits to unlock them, there's virtually no reversed engineered drivers. All those hundreds of thousands of Lumina phones? Now they're e-waste. Worthless.
Linux grew because IBM created the PC. Compaq reversed engineered the BIOS and everyone started making compatibles. Over time, BIOS and later UEFI became solid standards.
ARM may be fast, but the non-standard Basic Input/Output and device detection makes it nothing but potential e-waste.
Devil's advocate: anything that says Compaq on it is probably e-waste anyway, standards notwithstanding. Being standards-compliant isn't enough to save a machine from the landfill by itself; if those machines can't keep up with users' expectations, they too will end up discarded. Most devices that people throw away are "serviceable" machines. The people who rescue old hardware with linux and put it back into service are extreme outliers.
I used Compaq in my example because they were the first company to reverse engineer and IBM bios through some legal slight of hand (one group reverse engineered the entire BIOS and wrote a spec, an entirely different group re-implemented that spec, and the first PC compatible was born). I wasn't commenting on the quality of the brand at all.
I know why you picked it, and I wasn’t commenting on the quality either. (I loved Compaqs when I was young) I’m just saying that dumpsters are already full of old computers that could run Linux, but people aren’t doing it. They’re tossing the old Windows Vista laptop in the trash and buying whatever is on sale at Best Buy this week.
Hardly any of this matters in userspace or device-independent kernel modules, which is what 99% of developers work in.
>There will be N somewhat compatible ARM chips, that is to say they are somewhat incompatible.
This isn't how ARM's architecture license works. All ARM implementations are required to pass the same standard test suite.
>Architectural licensees get a set of specs and a testing suite that they have to pass, the rest is up to them. If they want to make a processor that is faster, slower, more efficient, smaller, or anything else than the one ARM supplies, this is what they have to do.
https://semiaccurate.com/2013/08/07/a-long-look-at-how-arm-l...
This isn't how ARM's architecture license works. All ARM implementations are required to pass the same standard test suite.
>Architectural licensees get a set of specs and a testing suite that they have to pass, the rest is up to them. If they want to make a processor that is faster, slower, more efficient, smaller, or anything else than the one ARM supplies, this is what they have to do.
https://semiaccurate.com/2013/08/07/a-long-look-at-how-arm-l...
Sure, for the instruction set all the CPUs are required to be compatible. However, Apple seems to be going in the direction of having many many hardware accelerators builtin to their SoC and integrated into their software ecosystem. I assume that if Google and Amazon were to build their own chips, they'd do the same. Those accelerators will not be intercompatible, and we'll have a dozen different vendored drivers, like how GPUs work.
> However, Apple seems to be going in the direction of having many many hardware accelerators builtin to their SoC and integrated into their software ecosystem.
I think this is overstated. There are quite a few differences between Intel and AMD extensions these days and they don’t create much of a problem. Apple’s architecture isn’t reliant on accelerators or special instructions to get good performance on general purpose code.
I think this is overstated. There are quite a few differences between Intel and AMD extensions these days and they don’t create much of a problem. Apple’s architecture isn’t reliant on accelerators or special instructions to get good performance on general purpose code.
But it could exist right? For instance, what if MS created an ARM variant with special instructions to accelerate C# garbage collection? You could imagine a world where vertical integration throughout the entire stack leads to software which kind of works everywhere, but only really gives a good experience on 1st party hardware.
I'm no expert but put too many extensions in there and you're looking less like RISC and more like CISC. It would make more sense on x86 platforms.
> Sure, for the instruction set all the CPUs are required to be compatible. However, Apple seems to be going in the direction of having many many hardware accelerators builtin to their SoC and integrated into their software ecosystem.
There is little evidence that Apple has built anything truly non-standard in the M1 so far, the closest thing they have is the TSO mode, and that's not an optimisation since it provides stronger guarantees (and thus lower performances) than normal. That cost happens to be recouped tenfolds when emulating a TSO architecture (aka x86) rather than having to do it in software, but that's got nothing to do with ARM workloads.
There is little evidence that Apple has built anything truly non-standard in the M1 so far, the closest thing they have is the TSO mode, and that's not an optimisation since it provides stronger guarantees (and thus lower performances) than normal. That cost happens to be recouped tenfolds when emulating a TSO architecture (aka x86) rather than having to do it in software, but that's got nothing to do with ARM workloads.
Not specializing in this area, I'm somewhat at a loss to understand what is so unique about the M1 that competitors could not implement similar in other ARM based systems or instead on Intel/AMD? Maybe another way to ask is what of the M1 performance is due to ARM and what from the Apple implementation?
I'm not a specialist either but my understanding is that Apple has thrown a lot of resources (and hardware) at the problem (and have been doing so for a while, the M1 is simply the apotheosis), and it has paid off: https://news.ycombinator.com/item?id=25257932
Nothing stops other ARM manufacturers from doing that, but it's expensive, and most manufacturers don't really have a reason to work this hard at it, they have a fairly low-margin biz and their clients aren't going to pay big bucks. For Apple however, these chips are completely structural, they already underlie huge amounts of their business and with the switch of Macs to ARM are slated to do so even more.
It may not be possible for x86 though, because of the architecture's complexity limits e.g. how wide you can decode, and more generally how much hardware you can keep fed concurrently.
Nothing stops other ARM manufacturers from doing that, but it's expensive, and most manufacturers don't really have a reason to work this hard at it, they have a fairly low-margin biz and their clients aren't going to pay big bucks. For Apple however, these chips are completely structural, they already underlie huge amounts of their business and with the switch of Macs to ARM are slated to do so even more.
It may not be possible for x86 though, because of the architecture's complexity limits e.g. how wide you can decode, and more generally how much hardware you can keep fed concurrently.
Being willing to be inefficient in terms of performance per square millimetre of silicon to be more efficient in terms of performance per watt was how it started. Having less cruft in the ISA that let them be more creative in other areas might be the more important factor now.
>Sure, for the instruction set all the CPUs are required to be compatible.
Isn't that the only thing we care about?
Anything else is a lot like saying that Intel based PCs aren't really compatible with each other because they can use different implementations of things like graphics chips, sound chips, and NICs.
Isn't that the only thing we care about?
Anything else is a lot like saying that Intel based PCs aren't really compatible with each other because they can use different implementations of things like graphics chips, sound chips, and NICs.
> However, Apple seems to be going in the direction of having many many hardware accelerators builtin to their SoC and integrated into their software ecosystem
I mean, so have Intel and AMD, for decades.
I mean, so have Intel and AMD, for decades.
Their specialized audio/ video/ image/ machine learning cores aren't helping with general purpose tasks like building code.
It's also not much different from the PC world where you have video cards and Nvidia's CUDA.
It's also not much different from the PC world where you have video cards and Nvidia's CUDA.
> Amazon, Google, Microsoft start building their own chips for their own clouds.
At least Amazon (Graviton) and Google (TPUs) already are. Google is also reportedly looking into its own ARM CPUs for its own mobile devices (Pixel line); if it does, I can’t imagine Cloud would be far behind.
> At least Microsoft is likely to sell their chips to third parties (they used to sell their software).
I would expect MS would keep its chips for its hardware, rather than selling them. But, sure, either they or Google might sell to partners, to help out the ecosystem for their OS's.
> If you want to develop for AWS you’ll be safer to have a laptop with an Amazon chip, if you want to develop for Google Cloud a Google Chip, for Azure a Microsoft chip.
In either case, cloud-as-dev environment is being actively pushed by all players, and negates that issue. It doesn’t matter what chip (or OS, or much of anything else) I have on my laptop if my dev environment is in the same cloud that I’m deploying to.
At least Amazon (Graviton) and Google (TPUs) already are. Google is also reportedly looking into its own ARM CPUs for its own mobile devices (Pixel line); if it does, I can’t imagine Cloud would be far behind.
> At least Microsoft is likely to sell their chips to third parties (they used to sell their software).
I would expect MS would keep its chips for its hardware, rather than selling them. But, sure, either they or Google might sell to partners, to help out the ecosystem for their OS's.
> If you want to develop for AWS you’ll be safer to have a laptop with an Amazon chip, if you want to develop for Google Cloud a Google Chip, for Azure a Microsoft chip.
In either case, cloud-as-dev environment is being actively pushed by all players, and negates that issue. It doesn’t matter what chip (or OS, or much of anything else) I have on my laptop if my dev environment is in the same cloud that I’m deploying to.
> 1. Amazon, Google, Microsoft start building their own chips for their own clouds.
https://aws.amazon.com/ec2/graviton/
> 5. If you want to develop for AWS you'll be safer to have a laptop with an Amazon chip,
Since I mostly work on Java that runs at Amazon, I develop locally using Amazon Corretto (https://aws.amazon.com/corretto/), less for performance than for greater confidence I won't run issues between JVM differences when deploying at AWS.
> Or we'll end up with 5 different laptops (unlikely) or one that connects to a remote desktop running in the appropriate cloud with the correct chip.
We're already there when deploying Python with dependencies that need to be compiled from a different OS. The options that I've used so far are 1. Only using pure Python dependencies, which mostly works, and 2. Running a container locally. Thinking about the CPU you're going to be running on might make sense if you're working on native code, but it probably won't be a big deal.
https://aws.amazon.com/ec2/graviton/
> 5. If you want to develop for AWS you'll be safer to have a laptop with an Amazon chip,
Since I mostly work on Java that runs at Amazon, I develop locally using Amazon Corretto (https://aws.amazon.com/corretto/), less for performance than for greater confidence I won't run issues between JVM differences when deploying at AWS.
> Or we'll end up with 5 different laptops (unlikely) or one that connects to a remote desktop running in the appropriate cloud with the correct chip.
We're already there when deploying Python with dependencies that need to be compiled from a different OS. The options that I've used so far are 1. Only using pure Python dependencies, which mostly works, and 2. Running a container locally. Thinking about the CPU you're going to be running on might make sense if you're working on native code, but it probably won't be a big deal.
N somewhat compatible ARM chips, that is to say they are somewhat incompatible. Remember the home computing landscape of the 80s / early 90s but also the diversity in server architectures and OSes
I'm not so sure. Or at least, I don't think a balkanized landscape like that would last very long before the market converges on some type of de-facto standard, much like things ultimately did in the 80's/90's, and late alternative ::ahem, Itanium:: failed to gain traction in the market.
Also, instead of a variety of (often vendor-specific) OS's, we're really only dealing with two major candidates: Windows & Linux. Linux with its multiple distributions is more complicated, although AFAIK the main server distros there are Ubuntu, Red Hat, Debian, and CentOS. So the chips that best support these OS's would likely be the one the industry converges on, assuming it's available as a commodity component. (i.e., not just in a propriety cloud) And it would be smart to make sure desktops/laptops can run the flavor of chips running in clouds because that's where much development/coding happens.
I'm not so sure. Or at least, I don't think a balkanized landscape like that would last very long before the market converges on some type of de-facto standard, much like things ultimately did in the 80's/90's, and late alternative ::ahem, Itanium:: failed to gain traction in the market.
Also, instead of a variety of (often vendor-specific) OS's, we're really only dealing with two major candidates: Windows & Linux. Linux with its multiple distributions is more complicated, although AFAIK the main server distros there are Ubuntu, Red Hat, Debian, and CentOS. So the chips that best support these OS's would likely be the one the industry converges on, assuming it's available as a commodity component. (i.e., not just in a propriety cloud) And it would be smart to make sure desktops/laptops can run the flavor of chips running in clouds because that's where much development/coding happens.
You’ll just be developing remotely. Amazon has had graviton for a while. Google has had TPUs you can use online but can’t buy locally.
What makes you think you’d have to have a local laptop? In fact, it’s in every behemoth’s interest to keep the good hardware managed and let the plebs work remotely using inferior technology.
What makes you think you’d have to have a local laptop? In fact, it’s in every behemoth’s interest to keep the good hardware managed and let the plebs work remotely using inferior technology.
Amazon already has Graviton 2, and considering the rapid pace they are switching over their infrastructure suggest to me they are going All In.
Microsoft and Oracle is partnering with Ampere. And Google is all over the map as usual, OpenPOWER, ARM, RISC-V. And I would not be surprised if they roll their own just like AWS. Marvell has ARM offering as well. ( They really should consider buying Ampere ) So it does seems like Server ARM CPU are consolidating to a few players anyway. And Despite what they claim, Ampere and Graviton 2 are pretty much customised from ARM's Server SoC reference design.
Apple will have a super large M1 like design for future Mac Pro. What I am interested in is if Apple would use this, assuming rack mountable Mac Pro for their own DataCenter usage? ( i.e Installing Linux ) Or Bring back Xserve?
Microsoft and Oracle is partnering with Ampere. And Google is all over the map as usual, OpenPOWER, ARM, RISC-V. And I would not be surprised if they roll their own just like AWS. Marvell has ARM offering as well. ( They really should consider buying Ampere ) So it does seems like Server ARM CPU are consolidating to a few players anyway. And Despite what they claim, Ampere and Graviton 2 are pretty much customised from ARM's Server SoC reference design.
Apple will have a super large M1 like design for future Mac Pro. What I am interested in is if Apple would use this, assuming rack mountable Mac Pro for their own DataCenter usage? ( i.e Installing Linux ) Or Bring back Xserve?
What do you mean by somewhat compatible? Why fragmentation when Arm sets the ISA standard?
The base ISA is set by ARM, but every vendor has their own set of features turned on or off, and their own extensions, and potentially their own way of laying out memory mapped IO and identifying peripherals.
Every vendor does not have their own set of extensions. Different x86 chips have different extensions (from a pre-defined set) - I don't see panic about x86 fragmentation.
It's not panic but this is really annoying like with AVX-512. The side effect is that people are making choice for the target architecture.
All of the predictions / claims except for (1) seem very incorrect to me
At the big corps that I've worked, my laptop is just a client to the machine that hosts the code & does the builds (that machine has been a giant Linux desktop & an ec2 instance)
We already see Apple chips in ec2. Today it's ostensibly "rent a machine to run your test suite" (although iiuc there's a 24h minimum rental), but I don't see any reason why it won't eventually be "just run your server on an apple cloud instance on ec2" (or develop locally in a container and deploy to that)
Software is actually reducing the friction of deploying to a different machine than you develop on, and the proliferation of high end custom chips isn't going to change that
At the big corps that I've worked, my laptop is just a client to the machine that hosts the code & does the builds (that machine has been a giant Linux desktop & an ec2 instance)
We already see Apple chips in ec2. Today it's ostensibly "rent a machine to run your test suite" (although iiuc there's a 24h minimum rental), but I don't see any reason why it won't eventually be "just run your server on an apple cloud instance on ec2" (or develop locally in a container and deploy to that)
Software is actually reducing the friction of deploying to a different machine than you develop on, and the proliferation of high end custom chips isn't going to change that
Nuvia is a startup aiming to make server chip in a more Apple style. They have some serious heaveyweight designers including people who worked on Apple's chips and have gotten a lot of investment.
https://nuviainc.com/blog
I don't think the most important thing here is the ISA. A64 is a pretty nice and I don't see any reason you would want to be incompatible with it, especially since getting an ARM architecture license requires you to be compatible with other ARM chips. But Amazon isn't going with Apple's very wide and deep pipeline strategy and there's nothing to say that other ARM chips would either.
https://nuviainc.com/blog
I don't think the most important thing here is the ISA. A64 is a pretty nice and I don't see any reason you would want to be incompatible with it, especially since getting an ARM architecture license requires you to be compatible with other ARM chips. But Amazon isn't going with Apple's very wide and deep pipeline strategy and there's nothing to say that other ARM chips would either.
There is no incentive for AWS to add restrictions like Apple with XCode. Indeed, I think that this would just reduce the amount of the customers they can reach.
I don’t think that other computers manufacturers are going to follow Apple’s lead. Maybe Microsoft will do it if they decide to get serious with their Surface line.
The one company I see benefiting the most from this is Qualcomm. They have the customers and the money to invest in R&D.
I don’t think that other computers manufacturers are going to follow Apple’s lead. Maybe Microsoft will do it if they decide to get serious with their Surface line.
The one company I see benefiting the most from this is Qualcomm. They have the customers and the money to invest in R&D.
Amazon already makes their own chips on the Graviton line. I wonder how long before you can get a graviton pc? maybe never?
I just had a vision: Amazon Basics Laptops
That's very interesting. A CR-48 looking, basic laptop with workable keyboard and trackpad. Chrome/Chromium OS (similar to CloudReady) since all the schools are on Google. If they could get it to $249 with reasonable performance, they could crush it.
Would they really want to use Google's OS? I would expect a FireTop, right?
Since we’re fantasising, I’d say a bare metal Linux distro — or a fork of Chromium OS — running as web client for AWS Workspaces. The downside is that you need an Internet connection at all times, and possibly a subscription.
To continue the fantasy: Amazon uses their experience with Stadia to deliver high-quality virtual desktops to thin client laptops.
You own nothing but the locked-down terminal that connects you to the AWS virtual desktop cloud.
You own nothing but the locked-down terminal that connects you to the AWS virtual desktop cloud.
I would assume that they would go under the Fire branding, like FireBook.
That's not a vision, that's a nightmare.
Wait till you hear the best part. Like the Kindle, they will ship it with ads as screensaver. Additionally, you will receive promoted notifications once in a while.
You pay 529.99$ upfront, or a monthly subscription, in order to remove the ads and enjoy your O.S. powered by AWS Workspaces.
You pay 529.99$ upfront, or a monthly subscription, in order to remove the ads and enjoy your O.S. powered by AWS Workspaces.
We're already living in Cyberpunk 2077...
And like their Halo Band, it'll listen in on your conversations to constantly assess your tone + upload semi-nude pics of you to AWS?
x86 line of processors is fragmented with tons of extensions.
There is more to a cloud than the chips. Having the cloud chip in your dev laptop wont mean you have the same memory/power/cooling/storage services. Code optimized on your laptop, despite having the same chip, wont necessarily run perfectly in the cloud.
Also it’s the architecture that matters, not the specific chip. And we got virtualization and containers for that.
I don't think any of the major cloud providers would be interested in #5. Better to have a wide open list of hardware that can develop for your platform. You can still run Windows VMs in AWS, Oracle DBs in Azure, etc.
re: 6: eh, it's less than that, as long as you're in the same architecture. Linux applications virtualized on M1, running on a Pi 4, and Graviton2 are going to be binary-compatible with each other, and although you'll get the extra atomic performance out of the M1, they won't be massively different other than just scaling up. Cross compiling after some testing to ensure the right atomic order was used should be fine cross-arch.
If one were to add more ARM extensions and actually push them for third-party usage, that might change though.
If one were to add more ARM extensions and actually push them for third-party usage, that might change though.
IMHO even if fragmentation happens (quite likely as RISC-V gains traction), this will force developers to actually take cross platform compatibility AND performance seriously.
It has nothing to do with their architecture.
Here are the facts:
The M1 is a 5nm chip, while the i9 is a 14nm chip! The M1 has about 16b transistor, the i9 has only about half of that amount.
No surprise the M1 is faster. Most credit should go to TSMC for being able to manufacture 5nm chips.
The M1 is a 5nm chip, while the i9 is a 14nm chip! The M1 has about 16b transistor, the i9 has only about half of that amount.
No surprise the M1 is faster. Most credit should go to TSMC for being able to manufacture 5nm chips.
> It has nothing to do with their architecture.
That it has zero to do with the architecture is a bold assertion (and seems unlikely).
In any event Apple would not have been able to manufacture / buy an x86 on 5nm so the architecture has quite a lot of influence on the performance of the latest Apple laptops.
That it has zero to do with the architecture is a bold assertion (and seems unlikely).
In any event Apple would not have been able to manufacture / buy an x86 on 5nm so the architecture has quite a lot of influence on the performance of the latest Apple laptops.
I made the following thought experiment. If we downscale the M1 to a 8b transistor chip and make it use 14nm technology, would it still be faster than an i9 chip? I don't think so.
Problem is your thought experiment doesn't work because you've ignored:
- The TDP of the M1 and the i9
- How each has utilised die area (e.g how much is devoted to CPU / GPU and accelerators)
When we see the version of the M1 for the larger MacBook Pros then the gap will become even bigger.
- The TDP of the M1 and the i9
- How each has utilised die area (e.g how much is devoted to CPU / GPU and accelerators)
When we see the version of the M1 for the larger MacBook Pros then the gap will become even bigger.
I think so. 3900X has 9.89b transistors and it is still faster than the i9.
This... isn't a fact. It's the opposite from what I've read - the architecture is just as important as the smaller nm process.
This post is good reading on the matter: https://news.ycombinator.com/item?id=25257932
This post is good reading on the matter: https://news.ycombinator.com/item?id=25257932
I really doubt the M1 would perform nearly as good if it was a 14nm chip with 8b transistors.
The nanometer process is not an actual standard. So it's apples and oranges to compare two fabs
You are right, there different ways to measure transistors, but if I recall it correctly this should not account for more than 20 or 30% difference.
of course, but no matter the standards, TSMC 5nm is significantly smaller (and efficienter) than Intel 14nm.
The surprising fact is that M1 in a 999$ MBA can beat a 3000$+ MBP 16”, or get near the performance of a desktop CPU that cost ~400$.
maybe you will be able to compile everything in the cloud and then it doesn't matter what type of computer you have
That would be the end of interesting software. Censorship at the compiler level.
> Back to mainframe / time sharing?
Back to the entirely proprietary mainframe of 1970 with dumb remote terminals.
But this time the mainframe performs pervasive surveillance.
Back to the entirely proprietary mainframe of 1970 with dumb remote terminals.
But this time the mainframe performs pervasive surveillance.
Just use the gap in performance among smartphones. M1 utilises the same high performance cores A14 has. And A14 is ahead of competing Arm by roughly 2 years. Here's your answer, hardware-wise.
But in the world of software things are far more complicated.
But in the world of software things are far more complicated.
The clouds should start building their own bytes so they can get cheaper bandwidth.
Those Redis results are very interesting. So interesting that it looks like something is wrong with the test.
Maybe the OS is a factor? I assume they're connecting to redis over domain sockets?
Maybe the OS is a factor? I assume they're connecting to redis over domain sockets?
redis is _the_ single threaded application
You need another process to insert/query to the redis process.
It would be awesome if they could test with Ryzen 5900x because the single core speed was greatly increased with it. That said, I still think the m1 would beat it.
This kind of changes the narrative about the Intel/ AMD competition of late. For the past few years people have been suggesting AMD has been hitting it out of the park in terms of performance. This suggests that's not necessarily the case.
AMD didn't have to hit it out of the park to humiliate Intel, they just needed to be competent. A professional ball club doesn't need a team of All Stars to embarrass a farm team.
AMD didn't have to hit it out of the park to humiliate Intel, they just needed to be competent. A professional ball club doesn't need a team of All Stars to embarrass a farm team.
Well note that this seems to be nearly all single-core (or low-core) benchmarks, whereas AMD's Ryzen performance recommendation has always been around its multithreaded performance, with its single-core performance called out specifically as being a compromise (until the 5000 series, anyway, which wasn't used here).
Something like an ObjC or C++ compilation test would be very interesting here.
Something like an ObjC or C++ compilation test would be very interesting here.
Yep.
It's a bit of tit for tat though. It's AMD's desktop CPUs versus Apple's new mobile CPU. But the benchmarks in question don't leverage all of AMDs cores.
Over the next couple years things should have more clarity when AMD moves to TSMC's 5nm CPUs and Apple releases their higher core CPUs.
It's a bit of tit for tat though. It's AMD's desktop CPUs versus Apple's new mobile CPU. But the benchmarks in question don't leverage all of AMDs cores.
Over the next couple years things should have more clarity when AMD moves to TSMC's 5nm CPUs and Apple releases their higher core CPUs.
Here you go (check for WebKit compiling time): https://techcrunch.com/2020/11/17/yeah-apples-m1-macbook-pro...
That doesn't compare against a 3900X or any other Ryzen CPU. It doesn't even compare against something not as heavily throttled as Apple's previous MacBooks.
The SQLite and Redis benchmark don't really make much sense here. They are more of a SSD/RAM benchmark than a measure of processor performance.
I'm curious if anybody tried AppleM1 with Unity3D? This guy reported dreadful compilation performance (11.6s on AppleM1 vs 2.3s on some old dual-core 2016 Intel model)
https://forum.unity.com/threads/unity-compilation-speed-is-s...
is unity3d running natively?
It definitely uses x86 emulation, if that's what you mean. But based on the these M1 threads I would expect M1 x86 emulation to work like magic, not be 5 times slower than some dual core 2016 model.
Rosetta does quite badly with JITed stuff (notably, it does very, very badly with x86 JVMs). I assume it'll be fine once native Unity is available.
Huh, this is surprising to me. Anecdotally, I tried Minecraft Java under Rosetta on my MBA, and it ran smoothly 2560x1600 resolution at 60 FPS with very few drops. Although I'd imagine that a JITed game might be easier for Rosetta to deal with, as it will be running the same code paths over and over again in comparison to a compiler.
I’ve never played minecraft, but is it generally cpu bound? The GPU is very fast, for a laptop-y thing, so that may be carrying it.
In synthetic tests, Java under Rosetta seems to range from twice to over four times as slow as native arm Java, depending on workload.
In synthetic tests, Java under Rosetta seems to range from twice to over four times as slow as native arm Java, depending on workload.
Yeah I just imagine that its a worst case scenario for Rosetta there. Possibly a lot of SIMD that isn't getting translated to neon simd.
I'm excited that this seems to reduce the time needed to compile Python regex by over 50%, something which Python currently offers no way to speed up or parallelize. You'd think that you'd be able to combine compiled regex to take advantage of repeated parts of patterns, or to compile regex across multiple processes and pickle them, but neither of those things are currently possible.
I’d like to see a “benchmark” about M1’s support for real world dev setup (docker, brew, libraries and so on).
And when can we expect the full support
Ideally, Docker et al will be ready by the time the MacBook Pros come out. Here is hoping.
Brew status: https://github.com/Homebrew/brew/issues/7857
Docker status: https://github.com/docker/roadmap/issues/142
From a quick glance neither have committed release dates, but "soon."
From a quick glance neither have committed release dates, but "soon."
I consider myself a "real" developer and I don't use any of that stuff. So far my observations about tool and library availability:
Node: build it from source at HEAD and it works fine. Will work out of the box in release 16.
Java: Get the Azul JRE, works fine.
Go: Has to be bootstrapped from HEAD.
c++ toolchain: works out of the box
cmake: build and install from source release, no problems.
bazel: still doesn't grok darwin_arm64, release build tries to x-compile everything.
anything that needs bazel: doesn't work due to above.
python3: comes in the box, works
R: no native package yet
Node: build it from source at HEAD and it works fine. Will work out of the box in release 16.
Java: Get the Azul JRE, works fine.
Go: Has to be bootstrapped from HEAD.
c++ toolchain: works out of the box
cmake: build and install from source release, no problems.
bazel: still doesn't grok darwin_arm64, release build tries to x-compile everything.
anything that needs bazel: doesn't work due to above.
python3: comes in the box, works
R: no native package yet
Caveat; if you need Java 15, Azul doesn't have that as yet.
That said, most people probably do not; 11 is still the most recent LTS version, which is what most people would be interested in.
That said, most people probably do not; 11 is still the most recent LTS version, which is what most people would be interested in.
I'm avoiding brew/docker myself on my main desktop as I've screwed it up a couple of times doing that before. Thus I fire up a t2.small in AWS to test docker images on. My local box is VSCode, Terraform, aws cli, Go, Python etc and everything just works (mostly through Rosetta)
I find it really hard to believe that a thin and light Macbook Air can be faster than a 12 core 3900X desktop for compiling large software projects.
I find the page confusing, isn't most about runtime performance of applications? From the title I would have assumed it is about compilation speeds and such.
Also I find it confusing that I can't find if the tests are multi-core or single-core performance? Why choose a 12C Ryzen when the tests are single core?
I'm probably too stupid for this.
Also I find it confusing that I can't find if the tests are multi-core or single-core performance? Why choose a 12C Ryzen when the tests are single core?
I'm probably too stupid for this.
Rumor is in a few months Apple will release a new chip that is made for pro computers. It will be in iMac and MacBook Pro 16in. I don't know what it is called but it had almost double the cache and core count of M1. That MacBook Pro is the one you probably want to buy for coding purposes.
Based on prior naming schemes, it will almost certainly be called an M1X. An A12X was more or less just two A12s stuck together, for instance.
That said, one might reasonably expect them to go even bigger for the iMac; it has much more thermal headroom than a 16" MBP.
That said, one might reasonably expect them to go even bigger for the iMac; it has much more thermal headroom than a 16" MBP.
When that iMac drops I'm going to grab it instantly. I am already allocating budget.
I've seen it referred to as the "M1X".
I see the M1 Mini fairly consistently outperformed by the M1 Air... anyone know why this would be?
Phoronix did a similar set of benchmarks with comparable results.
https://www.phoronix.com/scan.php?page=article&item=apple-ma...
https://www.phoronix.com/scan.php?page=article&item=apple-ma...
Surprised SQLite was faster on Ryzen. But looks like M1 outperforms nearly everywhere else!
We should ask sqlite's developer, but I guess it's not optimized for M1.
What would that involve? I'm not a SQLite developer, but I don't think they have a lot of platform-specific optimizations. It's written to be as boring as possible. In particular, unlike some other benchmarks discussed recently, SQLite doesn't have any x86-64-specific SIMD or crypto intrinsics/assembly that needs to be reimplemented for ARM.
That's what I was thinking, SQLLite probably did a lot of optimization for x86. Once they tune it for M1 I bet we'll see some phenomenal performance.
I mainly develop C++ targeted at x86-64 Linux.
I'm interested in hearing about others' experiences trying to develop for that target using an M1-based Mac.
For example, what's the status of VM systems with M1 Mac as host, and x86-64 Linux as guest?
I'm interested in hearing about others' experiences trying to develop for that target using an M1-based Mac.
For example, what's the status of VM systems with M1 Mac as host, and x86-64 Linux as guest?
> For example, what's the status of VM systems with M1 Mac as host, and x86-64 Linux as guest?
From what I understand, there is no way to virtualize an x86-64 operating system on the M1. You can run ARM Linux or Windows, but not x86-64.
From what I understand, there is no way to virtualize an x86-64 operating system on the M1. You can run ARM Linux or Windows, but not x86-64.
> From what I understand, there is no way to virtualize an x86-64 operating system on the M1.
I wonder if QEMU is up to the challenge. I know it's capable of emulating fairly recent Intel x86-64 chips. But I'm not sure what QEMU requires of the host hardware/OS.
EDIT: This seems relevant: https://www.techradar.com/news/you-can-now-run-linux-and-win...
I wonder if QEMU is up to the challenge. I know it's capable of emulating fairly recent Intel x86-64 chips. But I'm not sure what QEMU requires of the host hardware/OS.
EDIT: This seems relevant: https://www.techradar.com/news/you-can-now-run-linux-and-win...
This post seems reasonably thorough: https://blog.xojo.com/2020/12/04/about-running-windows-and-l...
Try with some real multicore workloads and the 3900x will be much further ahead
Anyone know if M1 is just a small first step and we're going to see big uptick in performance from here - or have we seen the big leap and we're back to 10% improvement a year from now on.
The M1 already has the widest CPU design of anything out there. It's possible that Apple will still be able to scale up even wider, but that wouldn't be a necessarily "safe" bet. There's nothing obviously on the table for a big uptick in IPC. Apples got a great trajectory and great engineers, of course, but there's nothing here where you can point to an existing thing and be like "now as soon as they add that, too, wow!"
It's "only" running at a peak of around 3.2ghz, though, so there's a lot of clear theoretical headroom on that front. But whether or not things like their cache or other subsystems can handle higher frequencies is unknown. But clocking up to ~4.5ghz turbo would be a potentially large gain - at the cost of also a huge uptick in power consumption, though, so Apple may just decline to go that route entirely, at least on their mobile CPUs.
It's "only" running at a peak of around 3.2ghz, though, so there's a lot of clear theoretical headroom on that front. But whether or not things like their cache or other subsystems can handle higher frequencies is unknown. But clocking up to ~4.5ghz turbo would be a potentially large gain - at the cost of also a huge uptick in power consumption, though, so Apple may just decline to go that route entirely, at least on their mobile CPUs.
> clocking up to ~4.5ghz turbo
How high they can go really depends on the process. TSMC 7FF silicon didn't go that high early on, max clocks really were improving as the process matured. This was very noticeable with AMD Zen 2, early dies topped out at ~4.2 (for all cores on the die), later ones often easily take ~4.4.
How high they can go really depends on the process. TSMC 7FF silicon didn't go that high early on, max clocks really were improving as the process matured. This was very noticeable with AMD Zen 2, early dies topped out at ~4.2 (for all cores on the die), later ones often easily take ~4.4.
How high it goes also depends on the CPU design. We know TSMC's 7NM can make CPUs that hit 4.5ghz, the Ryzen 5000 does this. It's also quite likely that TSMC's 5nm can still hit the 4ghz+ range in a CPU application.
What we don't know is if the M1 can actually run at those frequencies, too, or if there's other bottlenecks that prevent the M1 from clocking higher than it does.
What we don't know is if the M1 can actually run at those frequencies, too, or if there's other bottlenecks that prevent the M1 from clocking higher than it does.
You can look at Apple's mobile CPU performance gains over the past 10 years for an idea of what the current trajectory is.
There is likely to be a couple more big performance jumps similar to this when Apple releases versions of this with more cores.
There is likely to be a couple more big performance jumps similar to this when Apple releases versions of this with more cores.
Seems reasonable to expect that the version for 16" MBP/high-end 13"/iMac will be more or less the same thing but with more cores.
Apple tends to hold back performance on first gen products and then boost them dramatically in the next iteration.
I'm hesitant to buy a first gen product, but I really want to hop on top this bandwagon especially, since I needed a new computer last month.
It’s rumoured that they’re going to redesign the MBPs. I’m curious to see how they are going to improve the cooling system.
Just waiting for the 15"/16" version. I don't use an external monitor so 13" just doesn't work for me.
Same, im buying one the second its on sale
The values in the yellow/gold cells in the tables are really hard to read due to very low contrast.
5800x would've been a better comparison.
I dream of a day when Webpack builds won’t be so slow.
Once docker support arrives seems like a good upgrade.
This is so tempting, but I still struggle to make it over the privacy bump. I'm extremely bothered by the stuff I've seen stating that apple phone homes everytime I run an application.
You should research what Microsoft and Google send home then. You'll swear off computing entirely.
The problem with Apple verifying app signatures online each run is their implementation was crap and made Mac OS slow down to a crawl when they had problems. Incompetence not malice :)
The problem with Apple verifying app signatures online each run is their implementation was crap and made Mac OS slow down to a crawl when they had problems. Incompetence not malice :)
I think it's smart to be concerned and smart to make your own decisions about what you're comfortable with.
For what it's worth: Mac OS doesn't phone home on every app open. The result is cached on your computer for a few days[1]; this behavior was lightly confirmed by an independent researcher[2].
I don't think the caching really addresses the core concern. Apple has promised to provide an opt-out sometime in the next year[3], which is a superior fix. I personally will be keeping an eye on that committment.
[1] https://support.apple.com/guide/deployment-reference-ios/pre... [2] https://blog.jacopo.io/en/post/apple-ocsp/ [3] https://support.apple.com/en-us/HT202491
For what it's worth: Mac OS doesn't phone home on every app open. The result is cached on your computer for a few days[1]; this behavior was lightly confirmed by an independent researcher[2].
I don't think the caching really addresses the core concern. Apple has promised to provide an opt-out sometime in the next year[3], which is a superior fix. I personally will be keeping an eye on that committment.
[1] https://support.apple.com/guide/deployment-reference-ios/pre... [2] https://blog.jacopo.io/en/post/apple-ocsp/ [3] https://support.apple.com/en-us/HT202491
Can we say that M1 will be much faster when those applications are compiled natively for M1? As far as I know there's a translation layer (Rosetta) at the moment.
I don't see mention one way or the other in the article but everything that was tested has a native version already so I'd assume Rosetta was not at play in these numbers.
bollocks.
M1 devices are quality products. A more than necessary innovation. I expect them to do well if sold at reasonable prices.
The strategy of trying to sell them as outperforming the big boys on computationally intensive tasks, on the other hand, is plain absurd.
M1 devices are quality products. A more than necessary innovation. I expect them to do well if sold at reasonable prices.
The strategy of trying to sell them as outperforming the big boys on computationally intensive tasks, on the other hand, is plain absurd.
And, yet (with important caveats, especially around core count right now), they, er... do? I mean, what are you looking for? People to fake benchmarks to show them as slower than they actually are?
I do a lot of work for personal projects on an old 2.6Kg 2011 laptop I never felt the need to replace. I have no doubt I can produce benchmarks on this laptop involving daily tasks any average user does that would destroy any M1 device. Also I can do things on it no M1 device can reliably do right now and won't do for a while, perhaps ever or until M2 are already out (docker much?). My point is I am tired of useless biased benchmarks. Just tell people what they are: Laptops running on smartphone tech. Powerful enough to do most if not all daily tasks without any perceivable performance impact or inconvenience for the average user. Also way more efficient and cheaper to produce. It is very simple, and marketable. Just the integration with smartphone apps is already a super nice selling point, why not make it the core of the marketing strategy instead of those convoluted tricky and misguiding benchmarks and claims? What the Appleshpere is doing is comparing apples to oranges. Like: Hey look how much faster hackernews is compared to facebook! Ok, sure, whatever.
In general if you spend more money you get better performance. Isn't this, and shouldn't this be the case with Apple products as well. They cost more, no? Apple-tax.
The tested Intel chip (i9-9880H) has an RRP of 556.00, and is generally in practice found in laptops in the $2000 range. The tested AMD chip has an RRP of $500 (though that comparison is arguably less fair as the core count is an issue). The tested Apple computers both cost about $1000. That's for the whole computer, not just the chip. You can have one of these for as little as $699 (though you shouldn't; 8GB of RAM really isn't enough).
How is this possible?
I know the Apple M1 is fast but against a 3900X?
Is it mostly storage and memory affecting the results? (doesn't say what storage Ryzen uses).
I mean - I still have a hard time believing that a M1 can outperform a Ryzen 3900X if they benchmark something that uses the CPU 100% for a while - like raytracing.
Or do x86 just suck and we found out now when something else came out?
I know the Apple M1 is fast but against a 3900X?
Is it mostly storage and memory affecting the results? (doesn't say what storage Ryzen uses).
I mean - I still have a hard time believing that a M1 can outperform a Ryzen 3900X if they benchmark something that uses the CPU 100% for a while - like raytracing.
Or do x86 just suck and we found out now when something else came out?
Most of the article uses single core benchmarks. For single core, the 5nm M1 beats previous generation 7nm x86 handily.
For the current generation (which is almost impossible to buy) it's a push.
For multi-core workloads (mostly niche use cases) high core count processors perform better.
I assume when the M1x comes out, it will similarly dominate the multi-core workloads, if it does have the rumored 32 cores.
For the current generation (which is almost impossible to buy) it's a push.
For multi-core workloads (mostly niche use cases) high core count processors perform better.
I assume when the M1x comes out, it will similarly dominate the multi-core workloads, if it does have the rumored 32 cores.