This is part of why if you're overclocking your computer, you end up experiencing errors or unexpected crashes even when temperature doesn't go too high. Past reasonable tolerances, you can't just cool it more and expect it to work.
When you overclock you add voltage which helps with this which goes a long way. You would often hit thermal limits first, so heat dissipation is a major factor.
This causes heat and load spikes, and while you get no errors, the increased frequency doesn't give you any real world performance gains. Returning a to a slower configuration actually gives a much snappier and performant system.
It feels unfair to generalize across time and architectures
I stopped overclocking systems after Athlon XP. This is why I gave that example.
Even without overclocking and overheating, I've seen and still seeing partially cooked processors which shut-down half of their FPU pipelines to stay reliable albeit with orders of magnitude lower performance.
CPUs are much more complex with their MCE and more advanced microcode structures ever, and there's much more than meets the eye.
People push CPUs to absurd limits with LN2 cooling so they’d just not true.
AMD chips are doing similar clocks to Intel on TSMC N7, so Apple could (but won't) have a chip running way higher than the clocks they are currently shipping with.
Also, it's kinda inaccurate to imply any overclocked setup will crash, there's plenty of room unless they come turned up to the max from stock like the 12900k.
I expect Apple has an extreme focus on power efficiency and especially idle / leakage power, much more than Intel considering the core basically the same as they use in their phones. They also have a different approach to turbo / dvfs. So I would expect M1 to actually be a lot tighter than Intel and not have so much OC headroom.
Obviously you can buy timing with voltage to some degree, so there would be something there probably. Modern nodes are running into more problems with voltage induced breakdown though so the OC limit looks very different to what you can ship in a product. Has anyone measured M1's VDD?
> AMD chips are doing similar clocks to Intel on TSMC N7, so Apple could (but won't) have a chip running way higher than the clocks they are currently shipping with.
Not their existing microarchitecture though. They do nearly 2x the work per clock as AMD chips which necessitates more logic per stage. Getting a microarchitectural edge means making less logic do more work and it's very possible Apple have some edge there, it just wouldn't be near 2x IMO.
The silicon technology of course plays into it, but when you look at how fast individual transistors and the shortest poly to connect them can switch, speeds over 100GHz have been possible on 90nm. Today's cutting edge is probably over 200GHz (e.g., search ring oscillator). So it's not a fundamental switching speed limit of the tech that gets you.
I would say Apple could probably redo the physical design and synthesis work and minimal logic changes to target a faster and leakier device that's not suitable for phones but might be a little fairer comparison. It wouldn't put it at a 5-6GHz frequency, but could easily be enough to re-take these benchmarks and still be ahead on efficiency.
Not all work is created equal. Decoders on Arm are definitely parallel (= don't have more serial logic for wider decoder) compared to the variable length decode x86 is stuck with. And your backend ports are also parallel (although maybe scheduling isn't?). The only places where wider always means more logic per stage is caches - register file, L1/L2/L3, BTB. For example Apple managed to work some magic with a 3 cycle 192kB L1. AMD and Intel are at 4 and 5 cycles for much smaller L1's. Part of the reason for that is probably because Apple doesn't need to hit 5GHz and can afford more logic per stage.
And in any case, it's very likely you could just shove more voltage through the chip and get it to clock higher, since the current 3.2GHz is very far from what we know TSMC N7/5 can do. I don't think you'd need a rework unless Apple wanted to target 4.5+GHz.
> And in any case, it's very likely you could just shove more voltage through the chip and get it to clock higher,
Yes.
> since the current 3.2GHz is very far from what we know TSMC N7/5 can do.
N7/N5 can "do" 200GHz. 90nm could do 100GHz. The limit a device can do depends most highly on the logic.
> I don't think you'd need a rework unless Apple wanted to target 4.5+GHz.
3.2->4.4? I doubt it with any reasonable voltage that could actually ship in a device. Very hard to predict these things unless you've at least got basic shmoo plots and things like that in front of you.
x86 decode is parallel too
Something, somewhere does have to do a serial length decoding of course. But when you look at the L2 access latency and throughput (which is the minimum L1 fill latency), it's clear you could afford to do that part of the decode over more cycles.
New designs are not just predecoding lengths but entire uops now into the first level instruction cache which is the same concept they just call it a L0 and L1 rather than L1 and L2.
Overclocking is often a combination of overvolting (leading to more amps), allowing you to increase clock speeds.
The other sibling comment regarding distance isn't true. regardless of how insane your feedbacks are. Physical placement tools have always handled this in my experience (as a chip designer for 10+ years).
If this was released and allowed for relatively straightforward overclocking, user replaceable RAM and a full size GPU of one’s choosing, what could they charge?
The M1 Mad Macs edition would be loved by all 9 of us.
4-die Apple Silicon machines will surely come, but not with the M1 Max die. It'll be a new design.
Edit: thinking about this for a few more seconds, I realise this is a completely separate discussion, but I was just trying to think how Apple could accomplish the Quad branding even if internally its separate CPUs.
The only thing the Apple M1 has in common with ARM is the instruction set. The actual core design? Completely Apple. No Cortex X1s or A73s in there. Apple does use the stock ARM M3 in a few places IIRC but that's a very-low-power ~100mhz part for managing some internals.
Also, as for who can push the limits of ARM, Apple appears to know ARM better than ARM knows themselves. Both based on Apple's higher-performing core designs than ARM stock, and also because Apple cofounded ARM with VLSI and Acorn, and an Apple VP was the first CEO.
Edit: On that note, it's kind of ironic how every Android phone has the DNA of a company Apple cofounded and initially led.
You do realize that the ARM architecture existed for almost a decade before Apple was involved, right? From 1981-1990.
Apple was involved with ARM Ltd, the company that was formed when the chip division was rolled out of Acorn; not in the design of the original chips. Apple wasn’t significantly involved until the ARM6. Considering Microsoft was as involved with the StrongARM project, most of which has long since been integrated into the mainline ARM architecture, you could argue their DNA is just as integrated. By your logic, at least.
> Both based on Apple's higher-performing core designs than ARM stock
ARM’s vanilla cores aren’t intended to be high performance cores. They never sought that out until the recently started X-series, which even still isn’t designed to operate in the same envelope as Apple Silicon. Their designs have always been primarily focused on power efficiency with a secondary focus on drop-in generality.
I think the point about Android commentators is that they may not have been following Apple’s silicon development closely enough to know this, especially if they think that the M1 is the first in the line.
It's not just Android commentators. A surprising amount of people have the view that Qualcomm/Google/<whoever> will surely come up with better CPUs in a couple of years. Apple has been doing this for more than 10 years. They probably spent 4 or 5 years designing A4 before it came out. And A4 came out in 2010
Qualcomm is not going to make a better ARM Windows processor anytime soon. They had five years of exclusivity on Windows on ARM. Every single device they released was massively overpriced, had crappy performance, and until very recently, could not run 64-bit x86 programs at all (only 32-bit was translatable).
Someone is of course going to remind me that they bought Nuvia, and so Nuvia will change the boat around. I'm a skeptic. Judging by previous pricing, I believe that Qualcomm's chips and royalties result in disproportionately expensive hardware (every Windows on ARM machine to date, the cost of devices with Snapdragon 888+), and may not be competitive cost-wise as much as some would hope.
Also, Nuvia was designed for server processors, and is being retooled into a mobile processor. I'm going to bet that it's better than Qualcomm's current lot, but I doubt the single-core performance will be very strong compared to Apple. Qualcomm claims it will be "competitive with M-series," which considering M2 is going to be coming out before Nuvia isn't good news. Also, Qualcomm famously claimed that their Windows on ARM Snapdragon device was "competitive" with a mobile Core i5, but that was quickly laughed off the table when it went to reviews.
Depending on what you mean by significant, they have made those every year since the iPhone 4 came out.
Edit: Since the A6-era for CPU cores and and A10/11 for the GPU cores.
That “dippy little M1 MacBook Air” is damn fast. Even for single core tasks. I’ve owned one for a year now, and recently got the new M1 Pro with eight of the same cores, and single thread performance is not low by any sensible measure.
I fully expect this is what the new Mac Pro will look like, probably with multiple M1s.
(Also, RIP one of the most tinkerer-friendly Mac configs in a very long time.)
I expect them to come up with something much crazier with a newer design, perhaps in the M2 generation. Doesn't mean much, but the IRQ controller architecture and driver in these machines claim to scale to 8 dies, even though the existing implementation in the M1 Max is sized for 2. That's no guarantee they're looking at a product like that, but they might be.
Maybe in terms of raw FLOPS or something, but more importantly it has enormous levels of memory and storage bandwidth, which is what's actually important for most user workloads these days.
That's not even accounting for the performance of the GPU cores which can be used for a ton of multimedia workloads.
I've heard this tossed around a lot, but is there any evidence that it's actually true? I struggle to imagine a regular workload that benefits from 32gbps of bandwidth, much less a scenario where the average layman could saturate a 200gbps or 400gbps bus.
Since this is HN, many of us like… compiling, you know, stuff. It is a regular workload for many of us on here.
The main beneficiary of the M1 Max wide memory architecture appears to be the Haskell GHC compiler, which is very, very voracious when it comes to the memory consumption and the data bus width. Regular Haskell builds shift the data around at 35-40 Gbps on average, with the Haskell optimiser hovering around 50 Gpbs and easily peaking out at 65 Gbps on medium size projects. Since cabal (the Haskell build toolchain) for some reason can't fully utilise the «-j10» parameter, roughly a 1/2 of CPU cores are not utilised. Which means we can kick off another large Haskell build in parallel without affecting memory transfer speeds of the first build.
Rust release builds are a runner-up with 30-35 Gbps transfer speeds on average. Static type analysis and type inference in Haskell and Rust is hard, is complex and requires a lot of fast memory and benefits vastly from large CPU caches.
I have not attemped a Rust LTO build yet, but I would expect the LTO builds to like the wide memory bus, like, A LOT. In general, a LTO build (e.g. large C++ builds) is heavily memory bound and shifts data blocks, small and large, around extensively.
But an application is not very useful with a dataset, so many of us then like training our data models. Data model training can easily saturate 200 Gbps per a M1 Max CPU cluster.
Then the application needs to load the data in and usually do something with it. For example, issue complex queries to a graph database. Large CPU caches coupled with a wide data bus is a winner here.
All of the above are examples of real, practical and regular workloads.
I could easily imagine AI model training blowing up a memory bus, but every machine that isn't an M1 Pro or M1 Max is going to delegate that to a dGPU that is bound by PCIe bandwidth, not memory. Even then, properly-optimized CUDA programs will calculate most of the work on your GPU itself, constraining you to the 300-something gbps that your GPU is capable of.
Regardless, neither of these workloads are something that I'd imagine the average Macbook user doing on a regular basis. The only "real world" workload I can imagine that would exercise it is insanely high-res video encoding, which again, is only really going to be taken advantage of by a handful of users.
> I'd be inclined to agree, but my 16gbps i5 520m compiles Rust just fine. Small and medium-sized desktop applications aren't constrained by bandwidth as much as they are CPU-bound.
Gbps refers to the memory throughput, not to the memory footprint. A Haswell CPU equipped laptop with 16 Gb of RAM can compile Rust applications just fine; the difference is the time. Compile times are the single important delineating factor for software engineers.
> Even then, properly-optimized CUDA programs will calculate most of the work on your GPU itself, constraining you to the 300-something gbps that your GPU is capable of.
With all due respect, it is exceptionally unusual to train ML models directly in CUDA, which is a low-level proprietory Nvidia API. Of which CUDA is one, and there are several others as well (ROCm, OpenCL, CoreML, Metal etc), and they are swapped out for one another depending on what the underlying hardware actually is. ML training is done via the use of high-level ML frameworks (Tensorflow, NumPy, SpaCy, Pandas, SPARK and others), but not in CUDA – it simply almost does not exist.
Lastly, whilst the ML training undertaken on a high performant and an exorbitantly expensive dGPU itself would be substantially faster compared to 32 M1 Max GPU cores, one would yet be constrained with the PCIe bus data transfers speeds: ~32Gbps for PCIe v4.0 in the x16 lane setup (the high end of the commodity PC hardware today), and ~64 Gpbs for PCIe v5.0 in the x16 lane setup (not even unavailable for purchase today in PC laptops and desktops). With both being a far cry from the 200 Gbps of a single M1 Max CPU cluster.
Basically, all of this is configured at boot and much of it locked off. Apple have done a good job making it difficult to nuke these things from the OS level, for better or for worse :). I once overwrote all the GPIO registers and didn't even break anything (though the Type C controllers did crash, but a hard shutdown and boot fixed it - this was on an M1 Pro MacBook). It's in one of my streams somewhere...
Apple Marketing: This year Apple is going green in an all new way!
The crazy thing about using a Macbook Pro (with an M1 Pro or M1 Max CPU) is that, in single-threaded performance, it's really no faster than a dippy little Macbook Air. And at the end of the day, single-thread performance is more effective than multicore! TBH I think this tradeoff is the right one (that is, not overclocking Macbook Pros), but when the iMac Pro and the Mac Pro roll around… why not? Just go for it.