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...
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).
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.
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.
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.
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 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 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.
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.
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.
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).
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:
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.
> 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.
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.
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.
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.
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)
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.
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.
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.
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.
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.)
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.
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.
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.
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 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.
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.
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.
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.
> 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).
> 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.
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).
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.
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).
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.
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.
> 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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
Non-native English speakers (depending on their native language) will often use phrases like that. As that is how they say it in their native language.
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 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.
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.
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.
> 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.
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 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.
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!
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.
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.
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.
- 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?
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.
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.
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.
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.
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.
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):
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.
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.
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.
> 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.
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.
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.
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?
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.
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?
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?
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.
> 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.
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.
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 :)
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.
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.
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.
>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.
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.
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.
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.
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.
> 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.
466 comments
[ 0.21 ms ] story [ 300 ms ] threadedit: 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...
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.
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...
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
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.
Apple M1 and Only Fans
M1 earned it.
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.
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!
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.
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.
Maybe the OS is a factor? I assume they're connecting to redis over domain sockets?
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 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
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.
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.
That said, one might reasonably expect them to go even bigger for the iMac; it has much more thermal headroom than a 16" MBP.
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 m1 is interesting but I don't think its going to scale as well as a lot of people desperately want to believe.
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...