Ask HN: Can competitors catch up to Apple Silicon?
The Apple M1 Ultra SoC chip achieves 87% of the performance of the Intel 12900K and Nvidia RTX 3090 combined while only consuming 34% of the power. The entire M1 Ultra chip draws 225W at full load and 11w at idle. Forget the Nvidia card and the other PC components, the 12900K alone can draw 250W and the Ryzen 5950X 140W.
This is a seismic shift. Can Intel and the other players like AMD and Nvidia catch up to this peformace per watt that Apple has on their hands?
322 comments
[ 2.7 ms ] story [ 249 ms ] threadThere are many metrics that play a role for different applications. A modern Nvidia card is magnitudes faster than any CPU and the M1 GPUs. A Nvidia A100 card has HBM memory with ~2TB/s bandwidth.
On the other hand, there are areas where a ~5GHz intel CPU is competitive, or even older server chips with AVX can compete.
So let's see what happens when Intel and AMD step to smaller processes and switch to much faster memory (ddr5 as apple has done). Maybe the gap is large in energy consumption, but not in total performance.
No...
Intel Rocket Lake FP64: 32 Flops per core per cycle at 8 cores and 5GHz
Nvidia Ampere: 1/32 Flops per core per cycle at 2048 cores and ~2 GHz
Even though there are more architectural differences, there IS a difference in orders of magnitude ... for the things that you can do on a GPU (SIMD).
FP32 is 64x faster on NVIDIA Ampere than FP64 per: https://www.nvidia.com/content/PDF/nvidia-ampere-ga-102-gpu-...
Ampere has 60 TFLOPs of Performance on its top GPU, the Hopper per: https://en.wikipedia.org/wiki/Ampere_(microarchitecture). Which is roughly 50% to 100% faster than Rocket Lake depending and that doesn't account for the parallelism/memory benefits that comes with the GPU architecture.
A100 has 6912 cores (excluding tensor as they don't do 32-bit float math). Each core does 2 (32-bit) floats per cycle and runs at 1410MHz peak frequency. It is 826mm^2 and has an official 300w TDP. This yields 19491.84 GFLOPS.
Threadripper (Zen 3) has 64 cores. Each core does 32 (32-bit) floats per cycle and runs at 4300MHz. It has 8 CPU chiplets (80.7mm^2 each) and one IO die (416mm^2) for a total area of 1061.6mm^2. This chip yields 8806.4 GFLOPS.
Alder Lake has 8 P-cores and 8 E-cores. If you have an unlocked chip with AVX-512, that yields 64 (32-bit) floats per cycle running at up to 5.3GHz along with 32 (32-bit) floats per cycle running at up to 4GHz. Die area is around 215.25mm^2 (though much of that die area is taken up by the GPU) and it has a TDP of 150w (peak 241w). This chip yields 2713.6 GFLOPS for the P-cores and 1024 GFLOPS for the E-cores for a total of 3737.6 GFLOPS.
The first thing of note is that orders of magnitude is a gross overstatement as there isn't even a single order of magnitude of difference between the slowest and fastest systems here.
Dividing GFLOPS by die area gives 23.60 GFLOPS/mm^2 for the A100, 8.30 GFLOPS/mm^2 for the Threadripper, and 17.36 GFLOPS?mm&2 for the Alder Lake. Considering the GPU size of the Alder Lake, I suspect that GFLOPS per die area actually favors Alder Lake over the A100 (though this is also somewhat offset by the presence of tensor cores and other non-related stuff in A100).
Also noteworthy is that power is a much weirder metric due to how turbos affect all the things. I suspect this is where the A100 has a major advantage not to mention real GFLOPS dropping off steeply in long-running workloads (though this will affect all of these systems to greater or lesser degrees).
On the flip side, I should add that branchy code dramatically slows down actual performance on a GPU while only slowing down a CPU when a misprediction happens (in theory this should be only 1-5% of cases).
A more interesting question would be Alpha EV9 with it's proposed 1024-bit SIMD unit running at around 2GHz. That chip would have delivered 256 GFLOPS of performance per core around 2005. Scaling to a modest 32-core chip at 4GHz gives a very impressive 16384 GFLOPS while retaining all those CPU advantages too.
This leads to the observation that adding large SIMD/vector units to a CPU isn't really hard. A small, in-order core with very wide vector units running at a slower speed to conserve energy seems like an interesting idea and several startups are working in this direction (not to mention this being the basis of Intel's Larabee and later Knight's Corner designs).
As well as the Sony/IBM Cell processor used in the PS3. https://en.wikipedia.org/wiki/Cell_(microprocessor)
Wide SIMD or just in-order massive FP capabilities is not new. But it is hard to program for.
In many ways special purpose ASICs fill this role if you just need raw massive FP capabilities. Or eventually memory embedded computing can even take this further.
Load hit store issues where you could wait around almost a hundred cycles (and stall it because no OoO). Getting rid of SMT and adding complete OoO support would have been a much better result even if the die area was a bit bigger as a result.
The SPE had NO branch prediction and were pretty close to VLIW in design. It relied on the provably false trope of a "sufficiently advanced compiler" that can somehow solve the halting problem and of course leading to a 50-50 chance that you plowed ahead on the wrong branch and now must wait almost 20 cycles for everything to reset. As it only had 128 registers to unroll loops into, this problem is basically guaranteed to happen a lot.
They didn't provide any cache per core. Instead, programmers have to micromanage the 256k of RAM as if it were cache. Accurately predicting every possible memory pattern is impossible (it would require proving all execution paths which the halting problem says is impossible). Even modern GPUs include cache and choose the appropriate fetching patterns on the fly.
I'll also note that the SPE used a different ISA from the CPU (PPE) which adds yet another layer of headaches.
We'll never know how powerful the cell could have been because it had so many footguns that devs were seemingly incapable of avoiding all of them. These problems were called out by places like Anandtech or Real World Tech a year and a half before the PS3 launched and was then reiterated by the people using it.
Sony allegedly took to threatening teams that wanted to release their finished xbox 360 games before the PS3 version and even took to flying around a couple teams of cell developers to try to get games out the door quicker.
A system using the same ISA for both CPU and GPU isn't such a common idea in practice. There are supposedly a couple companies trying to use RISC-V to do this. I guess we'll have to wait and see what they can come up with. I certainly don't see them repeating these major mistakes.
No, that is a single order of magnitude.
There are 18 months worth of benchmarks from the Apple M1 that show that the gap really is large in total performance, and the "standard" M1 doesn't use DDR5, it uses the same DDR4 memory everything else uses. The observed performance gap is larger than what we can see happen between DDR4 and DDR5, and larger than what is expected to happen for AMD's and Intel's x86 between 7 and 5 nm.
For obvious reasons, desktop CPUs cannot use LPDDR RAM, because you can't put it in DIMM form.
Add.: or maybe I got it the wrong way around; smaller bus width but same performance due often being clocked faster. Either way I cannot find anything suggesting LPDDR offers practically faster performance on memory-bound operations than the DDR equivalent, but I'd love to see some tech details and numbers explaining how it works.
They run the memory cells and the I/O faster, and as of LPDDR4 it is now significantly faster than the DDR memory products available.
The gap between M1/M2 is pronounced in laptops but you can get faster (and hotter) multicore CPUs. Single-core is also not the same gap that it was because Rocket Lake has caught up and Zen3 had less of a gap to begin with.
https://browser.geekbench.com/v5/cpu/15482594
Samsung Galaxy S20 FE 5G = 2147483647 multi-core score https://browser.geekbench.com/v5/cpu/15129294
But only 8928 multi-core for the new M2.
Or maybe that page is kinda unreliable?
Sounds like someone managed to push their fake Geekbench score.
"Text compression: 22.8 TB/s". How long does the battery last though?
By contrast, Apple was able to just create a new CPU based on the much more modern ARM architecture, and switch to it like they have already done two times before (from 68k to PowerPC and then to x86), because they control the whole Macintosh platform. Compare that to Microsoft's largely unsuccessful attempt of selling ARM-based Windows machines.
How many more ARM chips have to get equivalent performance at a tiny fraction of the power before people will finally start considering that either AMD and Intel hire the most incompetent people out there or that ISA actually matters?
ARM could have extended their ARMv7 ISA to also be 64-bit without much trouble at all (plenty of space in the ISA). Instead, we got a ground up redesign that has more in common with MIPS64 than with ARMv7 (to the point that it's fascinating that ARM and some others bought MIPS just to get patent rights before immediately selling them off again).
I'm sure the go-to individual here is Jim Keller.
First, were his words free from constraint? If he said "x86 is crap and we should be using ARM or RISC-V" while working for those companies, how long would it take for him to be fired? Even if he were working at another company, saying that would burn a bridge that has kept him fed for decades. Would that be worth it?
He later said that if he were designing a new chip from the ground up, he'd probably go with RISC-V. He then proceeded to do that when he went to work for TensTorrent even though licensing ARM cores and adding their custom units on the side would be cheaper and faster to market. Given his connections, working with the AMD custom division would also be possible and would not only save some time and money for the startup, but would also have a massive set of available and heavily-optimized software working from the very start which would save even more money.
I'd say that his actions when free from corporate constraints show a definite opinion on the matter.
Like we just don’t know how much node size alone matters in the picture (or in the analogy, whether the improvement is only due to the bigger capacity battery vs better energy management at other places)
Yes, that's what interesting about this, how did they achieved the performance gap
In a few months we will have both AMD and Apple on the same size, so we will finally get some idea of how the baggage compare then. It won't be a long situation, Apple will relatively soon after release a new on a smaller size again.
The TSO memory guarantee X86 is probably the exception, since Apple supports it on their M1s too for emulation.
X86 instructions are variable-length: 1-15 bytes. And you do not know how long any instruction is until you read almost every byte of it (there is no length byte up front - it is just a list of prefixes). Thus to make a 4-wide decoder you need to ingest up to 60 bytes, and your decoder cannot start on instruction #2 till it finds the end of # 1. (Or guess, and rewind as needed). Much harder and a rather long dependency chain for decoder #4 to even get started.
Now say you want to go wider: 8-wide.
Arm64: copy and paste same decoders again. Done
X86: Now you need to ingest 120 bytes, and find even more boundaries, each depending on the previous - an even longer dependency chain. Decoder #8 cannot start till #1 - #7 are almost done. A mess nobody has managed to solve yet.
What an x86 processor does is fetch an entire cacheline of instructions at once. Working out which byte corresponds to instructions is a straightforward state machine--and state machines can be parallelized as reduction tree, because function application is associative! (This is usually described as "x86 processors start decoding, in parallel, every byte as if it were the start of a new instruction.) My guess for x86 is that resolving instruction length takes a single cycle, a single stage of the instruction decode pipeline.
It's actually hard to come up with x86 instructions that are 15 bytes long. Your typical general-purpose instruction is going to max out around 4 bytes (REX + other prefix + opcode + ModR/M byte), and even that's a little long. A "complex" memory instruction that moves a 4-byte constant into a register + constant offset will manage 12 bytes, but that's really the limit of practical instruction. So there's no point building a decoder capable of ingesting that many extra-long instructions a cycle because it is so synthetic a use case.
Sure, you could design a better compressed ISA for decoding than x86, but the impact of its complexity on processors is vastly oversold. Just look at how much die space the x86 decoders actually take up to see how little of an impact it has.
And how many instructions fit into it? Are you going to feed an 8-wide decoder with a single 64B cacheline? Especially with no promises that any instruction starts or ends on that boundary?
> It's actually hard to come up with x86 instructions that are 15 bytes long.
Something as simple and trivial as loading a 64-bit immediate into a register is a 10-byte instruction in x86... So for you to feed an 8-wide decoder even with such simple things as that, you're already at TWO cache lines ingested per cycle (80 bytes)... good luck with that...
I hear intel is hiring. Their current top of the line decoder is IIRC 5-wide. I am sure they’d like to hear your ideas as to how easy it is to decode x86 8-way
It will only take a 10 byte instruction if you can't zero- or sign-extend from a 32-bit immediate. Of course, if you were on ARM or most RISC processors, such an immediate likely requires at least two instructions anyways.
From paging through an objdump output of a large program, I'd hazard that average instruction size is about 4 bytes, maybe a touch shy of that. After all, instructions like "add rax, rbx" is going to be 3 bytes (two if you're only using 32-bit registers!).
> Their current top of the line decoder is IIRC 5-wide.
Looking at wikichip for the block diagram [1], that's 5 instructions per 16-byte window.
[1] https://en.wikichip.org/wiki/intel/microarchitectures/skylak...
“
As with previous microarchitectures, the pre-decoder has a throughput of 6 macro-ops per cycle or until all 16 bytes are consumed, whichever happens first. Note that the predecoder will not load a new 16-byte block until the previous block has been fully exhausted. For example, suppose a new chunk was loaded, resulting in 7 instructions. In the first cycle, 6 instructions will be processed and a whole second cycle will be wasted for that last instruction. This will produce the much lower throughput of 3.5 instructions per cycle which is considerably less than optimal. Likewise, if the 16-byte block resulted in just 4 instructions with 1 byte of the 5th instruction received, the first 4 instructions will be processed in the first cycle and a second cycle will be required for the last instruction. This will produce an average throughput of 2.5 instructions per cycle.
“
Of course internally the CPU has some huge number of registers. But it matters how many registers the machine code can speak of, and arm64 has 32 while x86 has 16. Consequently, x86 machine code has more cases of data flow obscured by spills to the stack. In a very sophisticated cpu, that might mean more decoding work to try to reconstruct the original data flow, or more likely (what’ll probably happen in most cpus), those spills will limit how wide the cpu can go.
I don’t know what limits you more in practice - the smaller number of registers or the variable length instructions. X86 throws at least one more limiter just for good measure: the TSO memory model, which causes memory effects to have dependencies between them in cases where they wouldn’t on arm.
Apple's M1 supports TSO (on ARM, obviously).
Is that accurate?
x86 launched in 1978. (64bit in 2003).
ARM launched in 1985. (64bit in 2011).
https://en.m.wikipedia.org/wiki/X86
https://en.m.wikipedia.org/wiki/ARM_architecture_family
> arm64 is the Apple ISA, it was designed to enable Apple’s microarchitecture plans. There’s a reason Apple’s first 64 bit core (Cyclone) was years ahead of everyone else, and it isn’t just caches.
> Arm64 didn’t appear out of nowhere, Apple contracted ARM to design a new ISA for its purposes. When Apple began selling iPhones containing arm64 chips, ARM hadn’t even finished their own core design to license to others.
> ARM designed a standard that serves its clients and gets feedback from them on ISA evolution. In 2010 few cared about a 64-bit ARM core. Samsung & Qualcomm, the biggest mobile vendors, were certainly caught unaware by it when Apple shipped in 2013.
> Apple planned to go super-wide with low clocks, highly OoO, highly speculative. They needed an ISA to enable that, which ARM provided.
> M1 performance is not so because of the ARM ISA, the ARM ISA is so because of Apple core performance plans a decade ago.
A715 in particular made it's decoder 20+% wider while reducing die area by 75% all due to eliminating 32-bit support.
A710 had a uop cache.
A710 had 4 decoders but it was like Intel's decoders where one (I assume one, but less than all of them) decoder could decode anything and the others could decode common instructions, but would block and send complex decodes to the complex one. A715 now has not just 5 decoders, but every one of them can decode anything reducing pipeline complexity and increasing theoretical throughput (depending on how often those complex instructions would be used).
A710 did instruction fusion in the uop cache, but A715 now does it in the L1 cache during fetch which increases effective instruction throughput by occasionally turning 2+ instructions into one.
Finally, A710 used a uop cache. The decoders would fill the uop cache at a rate of 4 instructions per cycle (less if one of those complex decodes happened). Once the uop cache would fill, it would provide 5 instructions per cycle to the rest of the frontend.
If A710 could prefetch and keep the uop cache full and there were always enough loops to reuse some parts while others were refilling, then you could keep the full 5 instruction theoretical output. A715 gets rid of all these exceptions making it more consistent.
In truth, the final difference is definitely less than 20% in the real world, but even a 0% increase in throughput while getting rid of 75% of your transistors would still be a massive win.
https://m.gsmarena.com/arm_will_drop_32bit_support_in_the_bi...
ARM designs both the architecture specification and some reference designs. 32-bit support has been an optional part of the specification since ARMv8 in 2011.
The article you link is saying that ARM’s Cortex-A reference designs will no longer include 32-bit support, which has nothing to do with Apple since Apple uses their own custom designs. Apple dropped 32 bit support in their own designs in (IIRC) 2016.
ARM is nearly as old as x86 and has had just as many evolutions in architecture as x86.
In today’s world of “tick-tock-tock-tock-tock-tock” it’s easy to forget just how fast the semiconductor industry was moving during the 70’s-80’s. Just about every processor sold introduced a completely new architecture
Look at the m68000 (1979) compared with the i8086 (1978). The m68k was 32 bits from the beginning, so while moving from the m68000 to the m68020 did add some instructions, there were no "special modes" for "backwards compatibility". All binaries that run on the m68000 can directly on the m68020.
Add an MMU and optionally an FPU to an m68020 (1984) or just use an m68030 (1987), and you have a fully modern system that can run modern software in 2022.
The i80386 (1985) is 32 bits and much more modern than the i8086, but real mode and 386 mode are completely different. Even with this modernization, Intel didn't bother with atomic operations, which is why neither Linux nor the BSDs support the original i80386. To run modern software, you'd need an i80486 (1989).
I think it's significantly reduced the time / cost / difficulty in rolling out a new instruction set architecture.
LLVM is specifically meant to be a compiler backend that you write languages frontends against. It sort of solves the expression problem for programming languages, and there's a whole range of production-ready compilers out there using it. When they add support for an architecture, every one of those languages also gets a large part of the work to support it done for them.
Also, CPU technology (outside of tiny embedded chips) is a lot more uniform with fewer weird variations or cost-cutting shortcuts, and transistors are ridiculously cheap. You can assume 32/64-bit, little-endian, twos-complement math, IEEE-754 floats, etc.
Microsoft failed at that multiple times in the past. Windows NT was initially available for multiple architectures, but that mostly ended with Windows 2000. Itanium got support until Server 2008 but non-server software support was very limited. Some Windows NT releases had a "workstation" label but application support, even from Microsoft, was between halfhearted and non-existent and the availability of some programs (such as Office) was almost a secret (I remember it existing for PPC, but never heard anything for MIPS or Alpha).
It's easy to take for granted how unusual it was the WinTel hegemony happened at all. As a fan of the breathtaking diversity of classic 80s desktop computing (Amiga, Atari, C64, Spectrum, MSX, etc), I lamented the steamroller of WinTel beige-box homogenization as it paved over so many divergent evolutionary branches. Yet the fact I can still install and run mass market consumer software products released in the mid-90s on Windows 11.
Yes, a high price was paid in both silicon and OS software to sustain such extraordinary backward compatibility - and is still being paid. While the utility of running circa-Win 95 software today in minimal, it's pretty amazing and I think the underlying stability in APIs, user interfaces and peripheral interfaces had under-appreciated positive impacts on the rapid prolife ation of desktop computing across society. Remember that the landline phone and cable companies initially envisioned the "home computer" to a be little more than a dumb terminal consumers would rent like a telephone handset. We're fortunate that vision failed when the commoditization of PCs allowed the home "internet terminal" to be a full user-owned and controlled computer with significant local processing and storage.
Wintel made a lot of good things possible that simply could never have happened in a fragmented market.
Modern cpus being able to run dos software is certainly nice, but it’s probably preventing intel/amd from performing some aggressive restyling and optimisation/refactoring to their isa and its implementation in silicon.
Apple on the other hand happily deprecates its own os releases and the hardware supported. Software retro-compatibility is then achieved in software (rosetta and such)
What's the performance hit/wafer space for that today?
Not really. Most of the legacy instructions are implemented via microcode anyways, so the amount of resources dedicated to legacy support is minimal.
Back in the 90's, there were more contenders than just AMD and Intel. Apple was using PowerPC chips, and on the x86 side there were several other competitors. Sure, it's been a bit one-sided since Apple went the Intel route, Via faded into obscurity and Transmeta went belly-up, but something else re-appearing as a viable, competitive platform is neither unprecedented nor unexpected.
It's the same with Apple's M1. I don't know anyone who is using it. People need obscure x64 instructions and CUDA. And that means you buy AMD CPU + NVIDIA GPU as the cheapest high-performance combination.
Also, I expect that the 5nm process is responsible for a large part of the power savings in the M1. So I would expect an AMD CPU on TSMCs 5nm to be pretty close in terms of performance per watt. It's just that the mainstream market isn't willing to pay the premium price for 5nm yet. So AMD produces "good enough" at a price that people are happy to pay, which means they need to hold off on going 5nm for now.
Riiight, but, OP isn't necessarily talking purely from an AI/ML use case.
Nope. They have that mix because they've decided to prioritize power consumption reduction (I suspect because they sell way, way more laptops that desktops/servers). It's actually a PITA for developers (you have to ensure that your compute-heavy threads are always on the performance cores), and conceptually confusing for users if they ever have to confront it. For pure performance, with no concern for power consumption, there are faster solutions.
If it’s proven that Apple can consistently provide better performance per watt per dollar and have enough chips available that people can actually buy, I think they can stand a chance to gain the AI market.
Tell that to AMD who's been missing out on the very lucrative government data-center market because they can't replace CUDA well enough. BTW, PyTorch and TensorFlow still ship without AMD support despite AMD's ROCm being around for 6 years now.
I don't know anyone who successfully trained a state of the art neural network on anything that was not NVIDIA. AMD keeps offering their own forks of PyTorch and TensorFlow, but last time I checked they were years outdated, and nobody uses them. So either PyTorch/TensorFlow are secretly sponsored by NVIDIA, or AMD's and Apple's CUDA replacements aren't mature enough yet. Given how many bugs there still are in CUDA despite them being around for a long time,
I'd guess that building a GPU-capable BLAS library is just a lot more work than one would think. I mean I also always wonder why CUDA comes with 400 MB of GPU shaders ... but apparently they need that to cover every edge case in a fast way.
FYI, this is the ROCm "getting started" guide: https://github.com/RadeonOpenCompute/ROCm-docker/blob/master...
NVIDIA has a GUI installer for CUDA.
My use of ROCm for signal processing has been pretty nice so far, and I think the ROCm BLAS library is up to par now.
I made a few pieces when needed: dense and sparse matrices, conjugate gradient, householder QR decomposition, other things. Wasn’t terribly hard.
I only needed to support relatively new GPUs, that’s one reason why. Another one, I based on DirectCompute not ROCm. The thing’s well tested (modern videogames are using compute shaders a lot), and works with all 3 vendors of GPUs. The main downside it’s Windows only.
> NVIDIA has a GUI installer for CUDA.
It’s still more friction compared to D3D runtime, which is an essential OS component installed and updated as a part of the OS.
To give you and idea, I need 24GB of GPU RAM to build a background separation model, but once it's finished, it's only 500kb of parameters and it can run on CPU in JavaScript in realtime.
As for the friction, CUDA is easy enough for motivated gaming kids to handle. AMD is not. But I'd predict that today's GPU enthusiast kids will become tomorrow's AI experts. As an example, look at the LAION chat which is a weird mixture of childish humor, gaming memes, and discussions about analytical approximations for probabilistic differential equations. (the Elucidated paper applied to Imagen's DDPM)
The main downside is the libraries: cuBLAS, cuFFT, and similar pieces of CUDA are manually optimized, and nVidia ships multiple versions of these compute kernels for different GPUs. DirectCompute doesn’t have an equivalent, need to implement manually in HLSL. This can be tricky because for optimal performance different chips need slightly different implementations.
Still, if you want to do floating point math with high performance for a lot cheaper than Nvidia, investing the time in ROCm is probably worth it.
"I can't believe Nixon won. I don't know anyone who voted for him."
Yes, a misquotation, but still. The Java/JVM world has dived into it. Java is all JVM code and it's platform-independent, and unlike, say, Python, the Java world never dived that heavily into native-interface code that tied them to a specific instruction set, they built a faster JVM instead of going out to native code. M1 is so good you can get better performance on a M1 MBA with significantly longer battery life compared to an i9 MBP of the previous generation.
Same for average users who don't do any of the developer things - HN itself is a bubble and most users don't know or care the uarch is different at all, they just know a base-tier M1 feels better than an i9, and they're right.
> So I would expect an AMD CPU on TSMCs 5nm to be pretty close in terms of performance per watt. It's just that the mainstream market isn't willing to pay the premium price for 5nm yet
Apple and AMD are going to be on the same node this year.
Technology is created by people, and I believe a big chunk of Apple's silicon team left last year.
So I hope we will see good performance from non-vertically integrated cpus soon. ie companies offering devices using a Qualcom or whatever cpu, which can run windows, linux, etc, not just tied into the Apple ecosystem.
Even if the comparisons to the RTX3090 were legit, all that power is still 'trapped' inside a Mac.
As the main reasons to have that level of power are gaming and VR, you'd be probably be better off having a bit less performance but on a Windows machine.
Apple utterly dominates the mobile phone CPU landscape, and it’s hard to see that changing. The reason is that they capture a huge slice of the profits in mobile phones. Something like 90%. For a while they capture over 100% of profits, because so many of their competitors were operating at a loss. This enables them to make investments their competitors can’t. Also because their competitors use commodity chips developed by Cisco and Samsung none of the Android vendors can use those chips to differentiate their products, which means even for flagship phones the CPU isn’t a unique selling points, so they can’t justify buying super premium chips. Without the guaranteed sales, the chip vendors can’t justify investing in making super premium chips. They’ve been stuck in this rut for almost a decade now, and still not found a way out. Success breeds investment, but without investment they can’t achieve success. It’s a negative feedback loop, compounded by a prisoner’s dilemma.
With desktop and server chips these factors don’t apply. Apple will never dominate the desktop and server CPU market because they’ve positioned themselves as a niche premium brand. They don’t even make servers, and the desktops they do make are ridiculously high end. They can’t go down market without eviscerating their margins. There’s still huge amounts of money to be made in those sectors, so vendors like Intel and AMD can afford to put in massive investment in new designs. They may be behind now, in some ways, but I don’t see any barriers to them competing in the near to long term.
That seems to be an interesting definition of "dominates". 14% of global smartphones from independents. 24% by Apple's claims. A curious kind of domination.
That's ok. Microsoft doesn't either ;)
(Rant specific to HN: some even are comparing IIS sales. Geez, it seems that most here are not willing to understand correctly what the GGP's comment pointed out is that Apple has a massive R&D budget that is unbeatable.)
Exactly right! It always amazes me to see the bubble some people here live in (and that's the best possible interpretation of these sort of comments; the worst is that it's a coordinated/paid astroturf attempt) We just spec'd several new computers here and they're all Xeon/NVidia. Nothing else can meet our needs.
https://www.tomshardware.com/news/qualcomm-confirms-nuvia-ar...
"Qualcomm acquired Nuvia in January 2021. The processor startup was founded by ex-Apple engineers who wanted to turn their talents to Arm-based system-on-chips (SoCs) for servers. Just a few months later Qualcomm provided an extensive update on its plans for Nuvia-technology SoCs, and it publicly pinned its hopes on addressing the always-connected PCs (ACPCs) market with a processor that could get in the ring and trade blows with the Apple M1. This could be an exciting introduction for the Windows ecosystem, if all goes to plan."
Talent can be poached [1] and Technology can be acquired [2]
[1] "Intel Poaches Head Apple Silicon Architect Who Led Transition To Arm And M1 Chips" https://hothardware.com/news/intel-poaches-head-apple-silico...
[2] https://www.qualcomm.com/news/releases/2021/03/qualcomm-comp...
------
The real problem - Apple is slowing down [3][4]
[3] "Apple CPU Gains Grind To A Halt And The Future Looks Dim As The Impact From The CPU Engineer Exodus To Nuvia And Rivos Starts To Bleed In"
https://semianalysis.com/apple-cpu-gains-grind-to-a-halt-and...
[4] "Apple M2 Die Shot and Architecture Analysis – Big Cost Increase And A15 Based IP"
https://semianalysis.com/apple-cpu-gains-grind-to-a-halt-and...
details from [3]
"It appears Apple has not changed the CPU much this generation. SemiAnalysis believes that the next generation core was delayed out of 2021 into 2022 due to CPU engineer resource problems. In 2019, Nuvia was founded and later acquired by Qualcomm for $1.4B. Apple’s Chief CPU Architect, Gerard Williams, as well as over a 100 other Apple engineers left to join this firm. More recently, SemiAnalysis broke the news about Rivos Inc, a new high performance RISC V startup which includes many senior Apple engineers. The brain drain continues and impacts will be more apparent as time moves on. As Apple once drained resources out of Intel and others through the industry, the reverse seems to be happening now.
We believe Apple had to delay the next generation CPU core due to all the personnel turnover Apple has been experiencing. Instead of a new CPU core, they are using a modified version of last year’s core. One of these modifications is related to the CPU core’s MMU. This work was being done for the upcoming colloquially named “M1X” generation of Mac chips. Part of the reason for this change is related to larger memory sizes and virtualization features/support. In addition, there may be other small changes as well, but we need hardware in the hand to analyze that. We also aren’t sure if Avalanche and Blizzard are the next generation cores or the current modified Firestorm and Icestorm cores.
Regardless of the paltry CPU gains and potential core architecture delays, Apple is still the leader in performance per watt. With Intel design teams starting to get back on track, AMD executing almost flawlessly, and Qualcomm coming in soon like a hammer with Nuvia cores, we aren’t sure if this lead will be sustained. The A11 to A12 generation was seen as Apple starting to asymptote out on gains with only a 15% gain, and the A13 to A14 looked even more weak with 8.3% gains, but now with no CPU gains, let’s cross our fingers and hope the A16 brings a large architectural change." source: [3]
With that said, of course competitors can catch up with what Apple is doing. Doing things you link to is how, and it's exactly how competition works. We'll have to wait and see what AMD and Qualcom end up actually releasing.
M2 is not a particularly large jump as these generations go, but it's on the same node and it's actually decent in that context.
I thought that’s how it works in Silicon Valley these days, people leave the company to create a startup with the intent to be acquired once they make enough progress.
If apple were planning a risc-v future then this seems like much ado about nothing.
If not they have plenty of cash to throw at the problem when it becomes a real issue.
I wouldn’t bet against them since they take secrecy very seriously and everyone is predicting doom and gloom without any idea what they’re doing behind the curtains.
Apple is playing a different game than it's competitors. They aren't looking to make performance gains no matter what happens to power draw and waste heat by endlessly cranking up the clocks.
The Anandtech deep dive into the cores used in the A15 and M2 show that Apple didn't just increase performance by about 18%, they cut power while increasing performance.
>Apple A15 performance cores are extremely impressive here – usually increases in performance always come with some sort of deficit in efficiency, or at least flat efficiency. Apple here instead has managed to reduce power whilst increasing performance, meaning energy efficiency is improved by 17% on the peak performance states versus the A14.
In our initial coverage of Apple’s announcement, we theorised that the company might possibly invested into energy efficiency rather than performance increases this year, and I’m glad to see that seemingly this is exactly what has happened, explaining some of the more conservative (at least for Apple) performance improvements.
https://www.anandtech.com/show/16983/the-apple-a15-soc-perfo...
Apple isn't winning at the game of performance increases no matter what happens to heat and power draw, because that isn't the metric they care about.
They care about performance per watt.
That's how dropping the M2 into the same entry level Macbook Pro they sold last year doesn't just bump up performance, it also gains you a couple more hours of battery life.
>MacBook Pro 2022 battery life tested — this is the longest-lasting laptop ever
https://www.tomsguide.com/opinion/macbook-pro-2022-battery-l...
Qualcomm got impatient and entered too early causing people to write them off.
The newest snapdragons have had gimped cashes for years now.
>could get in the ring and trade blows with the Apple M1
If you're aiming to match something that was on shelves for sale in November 2020 in late 2023, you're not really competing are you?
That's the biggest difference with x86 and ARM, ARM got a lot of breaking changes with their versions, while x86 don't (I'm not sure if there was any breaking change in the las 20 years at least).
Aren't those legacy instructions already emulated in microcode? I don't think they take up much physical footprint.
[0] Let me stop you right there before you suggest I recompile 15 years of operating systems, third party toolchains, and internal tools for ARM and then rebuild every intermediate container just so we can work around Rosetta shipping without necessary features. I know that you can ship a whole parallel stack of containers with ARM but that's not feasible in the slightest for anything but the most trivial use cases or entirely greenfield projects.
For work, I still have some third-party toolchains that were originally compiled on x86_64 linux in 2012. They are dockerized these days to make running these legacy toolchains easy. There is no possibility to recompile these on ARM to provide parallel containers that are compatible with Docker for Mac.
If x86 could get rid of the x86 instruction set and compile directly to something similar to uOPs, then some power reduction use and core area reduction could be achieved, but tooling cost would be immense.
I guess it should be slower too?
If TSO didn’t have a performance penalty, it wouldn’t need to be a separate mode. Also, it should be obvious that stricter ordering constraints inherently allow less parallelism, so lower performance.
If it were as simple as "they are the same once everything is decoded", then you'd expect a pre-decoded and pre-optimized program to be at least as fast, but it's not.
For as long as it can't run Windows, it's not a competitor.
A mass market chip will never survive the yield on such extremely large dies.
Most of mass market chips will be many times smaller physically to make money.
Apple does not make money on these chips.
You really believe that they treat their hardware as a loss leader when they are primarily a hardware company?
If your views on technological progress are informed by the 00s and 10s, and you think it is an S-curve, then today’s leaders might never be caught in an absolute sense, but the competitors will get arbitrarily close eventually.
https://www.tomshardware.com/reviews/intel-core-i9-12900k-an...
It's very workload-dependent, so it's difficult to say how much power a chip will draw in general. It's clear that Intel is still a bit of an energy hog, though.
- 225 W is for the M1 Ultra Mac Studio, whole system power consumption - that includes powering the TB peripherals if they exist
- Intel numbers are just the CPU (not even including the chipset) and will only happen if you don't cool it enough and it has to throttle
So yes, I'd rather have a M1 (probably a Pro would be enough) on my desk than an i9 under it. But I am weird and like cool and quiet, not larger numbers.
MBP is too damn fast (holy shit the build times!!) and too damn quiet to go back. The M1 put the i5 in a headlock and had it begging for mercy without the slightest bit of effort.
But this kind of question is not new. 10-20 years ago nobody would be thinking ARM could catch up to Intel. But also, is your question just about laptops and mobile devices? I don't see Apple taking on server markets, where the power per watt is perhaps less important. Finally, lots of people will be using non-Apple hardware for a long time (think anyone who isn't in Engineering at a company, they will probably be on a Windows system), which means there is guaranteed revenue for these other folks to compete, and possibly, catch up.
[0] https://www.zdnet.com/article/intel-invests-in-open-source-r...
While, as an HPC admin, I don't expect to see any Apple branded XServes in our system room for a long time (if ever), or their silicon on any other system, many HPC and data center operators would love to have servers with better performance per watt, because cooling these systems is a pain.
Everybody is moving to direct liquid cooling systems beyond a specific performance point, and this is not making things simpler.
- Can you run ARM system on any ARM processor, or are you limited by core architecture, endianness (BE/LE), and RAM addressing, forcing you to recompile for specific SoC? I honestly don't know what are the exact limitations.
- Can you boot any ARM processor in one specific way like x86 processor? No you can't. Every ARM processor has its own booting mechanism and you basically need to bend your system to it.
This lack of standardization is the reason, why Android phones does not have universal Lineage OS, but has build for phone X, build for phone Y, build for tablet Z and on the other hand this basic standardization is what will keep x86 alive for decades to come.
But, maybe there can be a build automation which can handle all the hassle and minimize the randomness?
You can build multiple functions to handle different architectures by function multi-versioning[1], not sure if it works for embedded though.
[1] https://gcc.gnu.org/onlinedocs/gcc/Function-Multiversioning....
I seem to recall trying to get uboot and and RPi to boot big endian at one point and it was infeasible.
Android phones have different builds because the hardware varies a lot, and because the OS is an integrated part of the product offering. It's not like the PC space where the hardware makers can't compete by better integrating the OS.
So it is pretty much given that we will see high-end Chinese CPUs by then.
https://www.reuters.com/technology/asml-still-has-no-licence...
On the Chinese side there is nothing short of a Manhattan project going on to create a semi-conductor industry that is outside US sanction power.
It will be absolutely fascinating to see the result of it.
https://www.reuters.com/technology/asml-still-has-no-licence...
Bob Dylan
The last will be first, and the first last - Matthew 20:16
> The Apple M1 Ultra SoC chip achieves 87% of the performance of the Intel 12900K and Nvidia RTX 3090
Benchmarks not run by Apple do not support this claim
In reality it is not competitive with chips five years old
Apple's competitors are already ahead of of Apple in terms of pure performance. "Catching up" is only a thing if you care about the performance/power ratio.
Correctly observing that someone is making false claims due to their allegiance to a brand name is not a personal attack.
.
> they are still quite significantly faster for an ultrabook
The benchmarks do not support this claim.
.
> and they do deliver the battery life.
Tom's hardware has them at 14 hours, the Surface Laptop at 17. Tom's hardware also says the Surface Laptop is faster. There are Lenovos with 35 hour battery life.
14 hours is pretty standard. The flagships of HP, Dell, Lenovo, and MSI also all do 15-17 hours. Apple's actually slightly behind the pack here.
Please note that battery life and CPU power are inversely correlated; you'll never find a laptop that's good with both, and if someone's telling you they have, they're lying to you
It's like saying that the car that delivers the most horsepower also uses the least gas. No, it doesn't, and you should know that.
In reality, these are both average middle of the road machines. They aren't particularly powerful when compared to one of MSI's beasts, and they aren't particularly battery lived when compared to one of those glorified tablets you can get.
.
> could intel or amd or OEMs achieve the performance to power ration soon ?
They did five years ago, according to the measurements and evidence.
I have never shopped for laptops according to their "performance power ratio."
Be node ahead of competition.
Solder memory on-package.
?????
Profit!
Not that Apple Silicon isn't impressive but I think we ignore the shortcomings and take a lot of what other processors do for granted.
Silicon often struggles on workloads that don't use some sort of hardware acceleration. If you never go off the beaten path it is very compelling.
This sounds insane (not in a good way). A 3090 destroys M1 Ultra in tasks like machine learning, 3090 being 5x-10x faster than the M1 Ultra.
[0]: https://www.youtube.com/watch?v=jCs27cNz6_k
Isn't the M1 Ultra Mac studio starting at $3999 MSRP?
Also, enthusiasts are usually willing to pay 2x the price for even just 2x the performance.
Could you point out which precise Apple device you are thinking of? Mac Studio with an M1 Ultra appear to be $3999 MSRP, and I was assuming that's the cheapest option for an M1 Ultra.
There's large diminishing returns as you push performance to the utter maximum.
Apple is pretty much a no go for gaming.
Yes?[1]
[1] https://www.paulthetall.com/crysis-for-mac-osx/
[0] https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw...
A lot of their best engineers left and joined the competition and a whole lot depends on them. The second thing that needs to happen is a serious restructuring of existing processors, to the point of rewriting parts from scratch. It will take some time but there are companies with the budget and the know how to do it.
And AMD (and probably Intel soon) has access to the same process technology as Apple so I think it is only a matter of time before you will see a catch up.
Here is an article on the subject; I am sure you can find others:
https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-...
ARM or x86? ISA Doesn’t Matter
2. So Apple gets exclusive rights to those new fabs for the first 2 years
3. As a result, Apple gets access to the latest performance benefits of the newest nodes 2 years before anyone else
4. Additionally, since Apple chips are SoC - EVERYTHING (gpu, memory controller, memory, cpu, etc) gets fabbed on thr newest highest performing node. This has never been done before because even Nvidia latest chips, due to cost, are typically in 4 year old nodes, along with memory controllers etc.
You can’t underestimate the massive benefit of having the entire SoC fabbed on a node that no other company can gain access too for 2+ years
Our CI does clean builds once a week, and the other builds somewhat regularly. Reducing the feedback loop by 10 minutes for a developers post merge check is a huge win IMO.
I don’t think many people are switching from linux and windows (although I switched from a linux thinkpad to m1 air), but those upgrading from intel macs to m1 macs are seeing huge jumps.
Anecdatum of one: I use my M1 chip for gaming (predominantly Minecraft with smatterings of Cities Skyline, Rocket League, etc.)
(I have trained MLs using the Metal version of Torch, too, but generally only tiny textgenrnn things for fun.)