Apple M1 vs. Ryzen 3900X vs. Intel I9 in Software Development
tech.ssut.me
tech.ssut.me
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.
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.)
In other words I think the problem has to do with the semantics of x86 more than the syntax of decoding x86.
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.
https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...
[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 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).
https://www.tomshardware.com/news/intel-announces-delay-to-7...
There's a reason the only laptops getting 10nm are low-quantity premium laptops.
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).
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.
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).
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.
https://debugger.medium.com/why-is-apples-m1-chip-so-fast-32...
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.
I mean, that's exactly how an 11th Gen Core laptop is constructed.
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.
but it's pretty straightforward to just copy giant buffers in order/out of order and squint really hard at the results
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 get that people on this site are excited, but please be excited about the right things.
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).
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.
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.
[0] https://aws.amazon.com/about-aws/whats-new/2020/11/announcin...
Under half the weight?
That's about a quarter lighter but not anywhere near half.
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 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.
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 true, then neither are close to the 2017 12" MB.
> and maybe just a tiny bit heavier.
It's almost a pound heavier.
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.
That's 90g of difference ... I'd say that qualifies for Ultralight still.
https://www.lenovo.com/us/en/coming-soon/ThinkPad-X1-Nano/p/...
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
It surely wasn't less than half as heavy. So what do you mean?
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
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!
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.
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.
- 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...
How instant? My late 2016 MBP wakes in around a second. My 2014 Mac mini usually takes only a few seconds.
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.
LG Gram 2020: 2.07 lbs
MacBook 2017: 2.03 lbs
MacBook Air 2020: 2.8 lbs
MacBook Pro 2020: 3.0 lbs
Also... I suspect benchmarking the LG or the 12" MacBook versus the Air would be pretty humiliating.
14-inch and 16-inch with same size but thinner bezels are expected to next year.
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.
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.
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?
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.
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 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'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.)
They're publicly available; the more datasets we have the better picture we get.
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...
Be careful. Benchmarking is hard. Before assuming malice, try to control for other variables.
also my macbook pro is slower.
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.
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
Would a native hadoop library make a difference?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
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.
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.
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.
Benchmark for OS+CPU stack should be their best combination not where one vendor has advantage.
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.
Comparing Desktop to Laptop is Apple to Oranges. Otherwise the desktop market will no longer exist.
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.
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.
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.
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.
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.
[1] https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...
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.
Especially if you are just doing lightweight web dev 16GB is more then enough (could probably get away with 8GB or less)
on my MacBook Air, I use azure data studio to connect to our MSSQL instances if I need a UI view of our database.
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.
As always, it depends what you're doing.
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
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.
We are to a point where we could be forced to trade performances for openness
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!
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.
AFAIK, that's not true with their ARM64 offerings.
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?
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 m1 is interesting but I don't think its going to scale as well as a lot of people desperately want to believe.
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.
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.
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 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.
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.
How they're gonna solve that is the big question.
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 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.
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.
Im sure Apple could produce something in the HPC space. The question is whether it makes financial and/or strategic sense to compete there.
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.
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!
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.
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.
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?
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.
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.
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.
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.
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.
The A12 and A13 (also 7nm) also did very well vs Qualcomm chips on the same process.
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 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.
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.
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).
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...
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...
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.
https://medium.com/swlh/what-does-risc-and-cisc-mean-in-2020...
confused.
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?
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).
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.
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).
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?
Maybe someday someone will reverse engineer it.
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.
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).
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...
https://www.tomshardware.com/news/Apple-M1-Chip-Everything-W...
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 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?
Amazing how the M1 has changed the landscape. If the MacBook Air could handle 2 external displays, I probably wouldn't even hesitate.
I would still cancel and order an M1 instead. It's that impressive of an upgrade.
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.
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.
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.
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.
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
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.
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?
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.
You own nothing but the locked-down terminal that connects you to the AWS virtual desktop cloud.
You pay 529.99$ upfront, or a monthly subscription, in order to remove the ads and enjoy your O.S. powered by AWS Workspaces.
But in the world of software things are far more complicated.
If one were to add more ARM extensions and actually push them for third-party usage, that might change though.
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 _does_ have one weird non-ARM extension; it can adopt an x86 memory model on demand.
https://developer.arm.com/documentation/dui0801/g/A64-Floati...
Not Apple Silicon specific though
>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...
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...
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.
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).
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.
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?
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 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.
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 :)
I would add that mac osx does have universal binaries for some years.
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.
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...
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.
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.
I mean, so have Intel and AMD, for decades.
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.
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.
It's also not much different from the PC world where you have video cards and Nvidia's CUDA.
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.
This post is good reading on the matter: https://news.ycombinator.com/item?id=25257932
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.
- 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 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.
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 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.
Back to the entirely proprietary mainframe of 1970 with dumb remote terminals.
But this time the mainframe performs pervasive surveillance.
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
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.
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.
Maybe the OS is a factor? I assume they're connecting to redis over domain sockets?
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.
Something like an ObjC or C++ compilation test would be very interesting here.
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.
In synthetic tests, Java under Rosetta seems to range from twice to over four times as slow as native arm Java, depending on workload.
From a quick glance neither have committed release dates, but "soon."
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
That said, most people probably do not; 11 is still the most recent LTS version, which is what most people would be interested in.
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.
That said, one might reasonably expect them to go even bigger for the iMac; it has much more thermal headroom than a 16" MBP.
https://www.phoronix.com/scan.php?page=article&item=apple-ma...
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?
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.
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...
There is likely to be a couple more big performance jumps similar to this when Apple releases versions of this with more cores.
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.
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.
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.
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 :)
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
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.
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?
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.