Ask HN: Can competitors catch up to Apple Silicon? | Hacker News Reader

Ask HN: Can competitors catch up to Apple Silicon?

145 pointscarlycue315 comments

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?

View on HN

You're looking in the wrong place. The magic comes from TSMC, not Apple. Apple's major innovation is in using their unrivaled bank account to pay TSMC for exclusivity on their newest fabrication technology. As competitors gain access to that TSMC technology they will match or beat Apple's performance. And if Intel succeeds in reclaiming the fabrication technology lead from TSMC (we'll see) then Intel will beat Apple's performance again.

I was under the impression that having it all as an SoC was a significant benefit by cutting down latency between components.

Intel, AMD, and Qualcomm have been shipping SoCs for years.

They don't have the RAM on package though.

This doesn't matter. I know no one will believe me, but there's no benchmark that can show the difference.

Isn't the packaging part of what makes the very wide memory controllers feasible?

Not really. GPUs regularly implement 256-bit or wider RAM.

With insanely high latency relative to a CPU…

Don't GPUs also typically have the RAM soldered on you the card, effectively "on package"?

That's my point; Apple's RAM soldered on package is the same as PC laptops with RAM soldered on the motherboard. Apple has no advantage from that.

You think Intel can right their ship? That's a fairly large order given some of the internal problems that have spilled into the public limelight. Takes a lot of energy to change that momentum.

AMD is going to be on the same node as Apple as of this year - Apple is not moving onto N3, they're staying on N5P, and Zen4 will also be N5P, so we can make iso-node comparisons.

This will be juicy come the fall!

I agree. And part of the magic comes from ASML.

I simply don’t believe this is true enough to matter. If it was a simple case of paying ASML X billions for their equipment, then we’d see more TSMC competitors.

It is entirely plausible TSMC co-developed some of ASML’s IP and has exclusivity - or that the tech to make a working process out of ASML machines is intrinsically hard.

84% of ASMLs entire business is TSMC, Samsung and Intel. It does seem like it's ASML or bust.

They're the only ones that make EUV lithography equipment. Competitors (Canon, Nikon) tapped out at DUV.

The ASML EUV machines are extremely complicated and rate limited by the polishing of the Zeiss mirrors which require 9 months to manufacture. Zeiss is in the process of scaling up, but in the meantime the EUV machines are very much backordered and that supply limitation is partially responsible for the slowdown in the release of updated nodes. There is an update of the ASML machines which are far more complicated that cost twice as much and should be part of a fab line in production in 2025.

To continue the tree of suppliers. Zeiss SMT would be nothing without:

HAP GmbH Dresden, MBFZ Toolcraft GmbH, Corning Advanced Optics, AGC Inc, RUAG Space, Schmolz + Bickenbach, RORZE CORPORATION and GEWO Feinmechanik GmbH

It sounds fun looking at how deep the rabbit hole goes.

I was only able to find that out because Zeiss SMT has an annual "supplier of the year" award.

And those depend on dozens of more companies, and those on dozen more. That is until suddenly a one man specialist retires his company and the entire chains grinds to a halt for months.

“What do you mean that Mathias is on holiday?”

That's not true. Compare the 8+ Gen 1 (TSMC N4) against A15 (TSMC N5).

Qualcomm prioritizes cost over performance and it shows. Look at AMD for a performance comparison.

But doesn’t your statement prove that there are decisions and things the user of a node can make which effect the end result? Therefore, is not just process node that matters.

I think it states that Qualcomm is not competing with apple on the success metrics that this post talks about re catching up, so you can't use it as a comparison. No idea how fast they could hit those specs up if they wanted to (was core to their business)

Obviously you can choose not to aim for the best possible performance in order to reduce costs. But for the companies that are competing for the absolute best performance at any cost, which doesn't include Qualcomm, by far the biggest factor determining that performance is the fabrication technology.

That’s an interesting take given this thread because Apple has explicitly stated they don’t prioritize performance, they prioritize performance per watt, which is not the same thing. And that also shows there’s a whole design space here and just focusing on one dimension, process node, is overly simplistic.

Top end performance is power limited, so optimizing for performance per watt is almost the same thing as optimizing for performance.

I’m not sure what point you’re arguing anymore.

I’m arguing against this statement. I don’t think it’s true.

“ You're looking in the wrong place. The magic comes from TSMC, not Apple.”

My point is a good process is necessary but not sufficient to make a part competitive with Apple on performance per watt. There’s a lot of “magic” to go around.

I think the argument is that Apple would have significantly less magic were it not for TSMC, which seems to be correct regardless of process or design (vertical integration).

Yes. Now every computers tend to be power limited (or say heat limited).

Where'd you see benchmarks of 8+ Gen 1? It was only announced about a month ago and isnt expected to even start sampling until later this quarter.

Ian Cutress https://www.youtube.com/watch?v=9QZIN8LFE-U

That’s a bold statement.

I don’t think we really know how much of the lead is due to Apple’s design.

I would bet it’s more due to fab than design, but the design plays a nontrivial role.

Just ARM is known to have much better per watt performance than intel. Folks are desperate that there be a single reason, but that is rarely the case.

The reality is that multiple factors are working in Apple’s favor. Process, architecture, design, investment, focus, OS… firing on all cylinders as they say.

Even there, it looks like Samsung is on track to beat TSMC to mass production of 3nm chips: https://www.reuters.com/technology/samsung-elec-starts-3-nan...

By this logic, you believe Samsung Exynos will be competitive with Apple’s A16 when it launches later this year? If it’s all in the process size - you’d expect this to be true but I’m betting A16 will continue the trend of Apple Silicon being dramatically superior.

Nanometers are fake though. Samsung 3GAE probably has worse performance than TSMC N4.

...except that Samsung demonstrably lies about every single thing relevant to assessing performance, benchmarks, release dates, etc.

that's absurd. fabrication depends on a design, and Apple has done years of research into low power performant designs, going back to be a cofounder of ARM.

Citation : https://en.wikipedia.org/wiki/Arm_(company)#Founding

This is just absolutely incorrect.

Design is over half the battle, look at Qualcomm n5 performance vs Apple M1 on n5 performance.

It's not even comparable in anyway.

Even AMD 6900U struggles in many regards compared to M1 pro, and even more so at performance per watt.

For example Cinebench runs at 118% more power draw on the Ryzen at only a 11% multi-core performance advantage.

Qualcomm chooses low cost over performance on purpose. AMD 6900U is still at a process disadvantage compared to M1. AMD's comparable chips won't come out for many more months.

You're still wrong. Design counts. Apple has a huge design lead here. There's no way to successfully obscure or distract from that fact.

It’s obvious they invested so much design energy making A series much faster every year to build the competence to build the M series the way they wanted it.

> This is just absolutely incorrect. Design is over half the battle

Completely agree. There are many ARM SoCs available in the market, and Apple's ARM SoCs outperform most of them. Apple has also made significant design changes in its SoCs that really does differentiate it from current Intel and AMD chips and these design changes do give it a performance advantage. The unified memory access architecture (I think pioneered by SGI), is a good example of one such architectural difference. And ofcourse, manufacturing these SoCs on newer node tech also allows Apple to pack more transistors in their chip than Intel and AMD currently can. Altogether, it is undeniable that Apple engineers have created a great piece of hardware and a very decent and viable alternative to Intel and AMD chips.

But ... better tech doesn't always necessarily translate to more sales and popular acceptance. AMD is a great example here - despite having better technology than both Intel and Apple (on CPUs and GPUs), it still struggles to compete with either and is nowhere near the market size or capitalisation of either Intel or Apple. However, here we are not talking about a product from a new startup or small business but Apple - A huge behemoth with a fantastic team of management that knows how to sell stuff and make a profit. So it's not at all far-fetched to assume that the Apple Silicon chips are here for the long term and will continue to be a viable competitor to Intel and AMD chips. But how are they competing, and what company's vision will win in the long term?

Apple's long term business vision is to continue being a hardware + software company while evolving & increasing its recurrent revenue from services that is tied to monetising the personal data of its users. I have no clear idea of either Intel's or AMD's future business visions (which is perhaps telling in its own way of how both businesses are today), other than that they want to continuing innovating and selling the hardware that is their core business (CPU, GPU, Fab tech etc.) that is more "open" to integration with other systems (software and hardware).

So, keeping those visions in mind, let's compare the pros and cons of Apple and AMD / Intel chips.

Apple Silicon - Pros:

1. Latest tech, innovative design offering better performance in some areas. 2. Low power usage, great battery life. 3. Cheaper. 4. "Integrated" RAM leading to better performance. 5. Highly integrated with Apple ecosystem (Apple hardware + software + web services).

Apple Silicon - Cons:

1. It is not sold as stand alone part. 2. It is a closed box system with no hardware literature available to build alternative platforms on it. 3. Highly integrated with Apple's ecosystem. 4. Has built-in planned obsolescence (CPU is soldered, RAM is soldered, bootloader can be locked anytime). 5. Low power usage that unnecessarily sacrifices performance is undesirable in a desktop computer.

As is evident, the pros and cons of Apple Silicon are tied to the business vision of Apple - they believe that the best way to make recurrent revenues by selling Apple services, is to create a closed-box system and tightly integrated ecosystem that forces its users to only use Apple hardware and services. Built-in planned obsolescence makes it easier to sell new system. Similarly, AMD / Intel's business vision is reflected in pros and cons of their product too:

AMD / Intel CPUs - Pros:

1. Good support for multiple OS platforms. 2. Backward compatible (x86). 3. More open, better hardware literature on their SoC's support creating new platforms. 4. Better integration with other hardware allows more flexibility to users in building custom hardware. 5. Supports repairability (CPUs can be replaced and upgraded more easily in the same system, integrated GPU doesn't prevent you from adding and using a more powerful GPU etc).

AMD / Intel CPUs - Cons:

1. Lagging in newer tech. 2. Maintaining backward compatibility comes at a price - more complexity, limits exploring new designs and architectures. 3. Supporting multiple platforms can be somewhat limiting as hardware performance varies depending on software quality of the platform.

-----

As AMD and Intel have shown in the past, both have had better tech than the other at some point. It's the same today with Apple innovating and currently having better tech than AMD / Intel. So it isn't exactly a question of will the better tech win. What matters is who can sell their tech better.

> increasing its recurrent revenue from services that is tied to monetising the personal data of its users.

My understanding is that they’re more responsible than other services with respect to personal data. Unless I’m mistaken, their strategy isn't to monetise and sell data, but is instead to sell services that allow users to interact with their own personal data, which is incredibly rich given the ecosystem that Apple Watch and HealthKit offers.

As an Apple user, I see it more cynically now - their whole idea of "privacy" has morphed into a strategy to prevent their competitors access to the personal data of the users, while ensuring they have more invasive access to it. This idea is offensive to me. Preventing data collection is the first step to user privacy. Once BigTech has your data, they can do anything with it in the future (despite what they say today) because of the lack of appropriate law and regulation to prevent this. I see us heading to a dystopian future where BigTech evolve into data brokers.

>Preventing data collection is the first step to user privacy.

Apple are the first to actually do this properly by cross-app tracking, forcing developers to outline data collection statements, and providing clearer sharing acceptance pages.

> Once BigTech has your data, they can do anything with it in the future (despite what they say today) because of the lack of appropriate law and regulation to prevent this.

This is entirely incorrect. HIPPAA and GDPR are very clear about PII health data, and a large corporate like Apple will be fined through the teeth violating it. Changes to the PP are communicated, and allow the user to opt out by discontinuing the service. Sure they’re sometimes opaque, but Apple has built a reputation on responsible data policies, which are frequently contrasted with those of other big tech data factories like Facebook and Google.

If I can't prevent Apple from collecting my personal data, I consider it as an intrusive violation of my privacy by Apple. Health data is a very small subset of personal data that does have some regulations. Its scope needs to be expanded to cover how BigTech, like Apple, use it. As for Apple building a reputation of having "responsible" data policies, the cynic in me remembers how Google too sold the same bullshit as "privacy respecting" company a decade or two ago - Apple seems to be following the exact same strategy with its marketing while slowly but surely escalating data collection.

>” 5. Low power usage that unnecessarily sacrifices performance is undesirable in a desktop computer.”

This is a temporary matter. For notebook computers, Apple made the obvious decision to optimize for power usage. But in interviews their engineers have signaled that when the time comes they will be just as capable of optimizing for performance on a future Mac Pro.

Wrong, the majority of Apple’s thermal efficiency comes from superior design which in turn comes from the fact that they were able to design it from the ground up with no backwards compatibility requirements (since they don’t have any customers of the chip besides themselves).

This is false. Apples arm chips are compatible with the normal arm instruction set. Evidenced by Linux trivially running on it.

Well it’s an ARM chip. it’s still not backwards compatible..

With AArch64 yes, but that's a relatively recent 'clean break' ISA. It's not an extension of Arm32.

lol this will age well. i remember designing CPUs at intel when they had like a ~2.5 gen process lead (literally 4-5 years) and the result was still barely better than competition.

what outsiders don’t realize is intel management never had to deal with competition. they spent their entire careers fighting each other in petty internecine political battles. if you think intel vs amd is a feud, you haven’t seen intel arch/design vs intel fabs. and in that kind of environment, loyalists and politicians are promoted, not people willing to critically inspect your own processes and improve things.

end result: intel has a massive competence gap. in the extremely unlikely scenario where intel can regain the process lead, they will still be behind the curve on innovation and execution.

I didn't know the word internecine, it's actually really useful and relevant in many situations, thank you!

> internecine, adj.:

> destructive to both sides in a conflict.

I find myself googling "etymology {word}" a lot recently; here inter is between like in intercontinental, and necine is death like in necrosis.

And inter is apparently the origin of intel, which is topical, and suggests Intelnecine, adj: destructive to all factions within Intel, or any company with a destructive amount of in-fighting.

https://www.etymonline.com/word/internecine

(Ex-Intel, agree)

What do you think of the new management? Too difficult to turn the tanker?

Looks bad. I have two examples to go with:

- The Sapphire Rapids validation catastrophe proves they haven’t learned a damn thing about high quality first silicon even after all these years of getting their asses handed to them by AMD/Apple on fast cadence updates.

- Arc, enough said.

Pat Gelsinger made some big moves on his direct reports but he doesn’t have the time to perform the necessary mass purge of the mid/mid-high level management (i.e. the baby VP tier). When you run a company with 100k staff you have to delegate a lot of things, but the problem is a huge amount of the toxic management are still there, hiding in nooks and crannies and surviving.

Intel is currently throwing a lot of money around to hire people from the companies thrashing them (got a text message from a VP a couple months back), I get the feeling the Intel immune system will spit them back out upon detecting deviance from “the Intel way”.

It’s true 5nm definitely gives M1 an edge, but Apple’s ARM chips have lead the pack by a mile in performance for a long time, at comparable nodes. To say all the magic lies with TSMC is to claim that with M1 Apple suffered a huge loss is leadership position in terms of design, saved only by TSMC. I don’t see how that’s a credible claim.

Generally agreed, however apple's arm cores have substantial advantages over all the other common arm cores. The M1 maintains great perf/watt (common to arm), but is a very competitive core at any power level.

A13 and Zen 2/3 were all on TSMC N7, but A13 still crushes in performance per watt by a HUGE margin.

To reach 87% of the perf of a 12900K at a max clock of 3.2 GHz versus the 12900K‘s monstrous 5.2 GHz, the M1 has something like a 75% IPC advantage.

Are you seriously claiming that you expect a single node shrink from Intel 10nm (roughly equivalent to TSMC 7nm) to Intel 7nm (equivalent TSMC 5nm, the M1’s node) to give Intel an enormous 75% increase in IPC such that they’d be able to compete on performance per watt by not having to clock so stratospherically high (with the attendant voltage penalties) to compensate for their low IPC?

That would be an unprecedented outcome for several node shrinks, let alone a single one. It’s Apple’s super-wide design that’s the primary factor in the IPC here. To pin it all on a single node shrink is magical thinking.

I'm not claiming that I think the parent's claim is true, but Intel really fucked up 10nm, and I mean worse than they fucked up the shrink to 14nm which fundamentally changed their unit economics.

So let's be clear, it's not like the good old days where Intel might get ahead by moving to 65nm earlier. TSMC 5nm is competing against Intel 10nm at a point where Intel 10nm can't really beat Intel 14nm. I know the actual measurements are bullshit (I've got flak for complaining about angstroms before) but TSMC 5nm is a long way ahead.

Er, no, sure it's a contributing factor. But Apple's lead in perf/watt is much higher than you can attribute to the process.

Their GPU is similarly impressive, with a minimal TDP it handily crushes any other iGPU.

what’s your superpower?

I’m really rich.

That justice league exchange is what came to mind when I read your comment

The picture you're painting is far too simple.

There 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.

> magnitudes faster

No...

100+ vs <20 TFLOPS

...which is one order of magnitude.

Not if you use base 2. And sometimes I like to use base 1.00001 for a grand effect.

https://en.wikipedia.org/wiki/FLOPS

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).

This is because FP64 is emulated on the NVIDIA Ampere as it is missing dedicated FP64 hardware. This is not a fair comparison.

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.

Let's analyze 3 real cores.

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).

> 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.

The Cell was a very flawed implementation.

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.

> here IS a difference in orders of magnitude

No, that is a single order of magnitude.

> 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.

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.

Apple uses LPDDR RAM which is a very different protocol. It is actually faster than DDR, and this may be a big part of the performance difference.

For obvious reasons, desktop CPUs cannot use LPDDR RAM, because you can't put it in DIMM form.

Are you really sure about that? I thought LPDDR is all about low power consumption - running at half the frequency but making up for it by twice the bus width, ending up at same performance but with an emphasis on the LOW POWER part of its name.

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.

In Apple's case, it's the same width (M1/2) or much wider (Pro/Max/Ultra) and also clocked faster (6400 vs. 4800).

LPDDR used to be about power consumption. It is not any more. DDR uses a lot of power for I/O and SERDES links to maintain a modular form factor, and LPDDR uses a lot less power by having worse signal integrity and lower swings.

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.

Yeah I was imprecise there, the M2 is using LPDDR5. So I'm expecting Apple to stick with that for future macs of this generation.

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.

And M2 benchmarks aren't even out yet. The topic will be yet more interesting in the coming months.

They are absolutely out, because the M2 MBP is publicly available.

https://browser.geekbench.com/v5/cpu/15482594

Oh so the M2 is a lot slower than Samsung phones?

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?

That number is 2^31-1, the maximum number representable as a signed 32bit integer.

Sounds like someone managed to push their fake Geekbench score.

"Text compression: 22.8 TB/s". How long does the battery last though?

Yes, that's what I wanted to say. Geekbench scores aren't that trustworthy.

"You can post obviously absurd scores" does not logically lead to the conclusion "therefore none of the scores can be trusted."

"You can post obviously absurd scores" makes it more difficult to believe a very good score for a very new device that has mostly been criticized in reviews: https://www.digitaltrends.com/computing/m2-macbook-pro-perfo...

Regardless of how fast the phone is, it’s gonna throttle way down under any heavy load, unless you keep it super cool.

They probably dipped it in liquid nitrogen during testing ;)

My point is that benchmarking as a whole need a bit of time to mature with the help of real and diverse usage. Not just two weeks of GeekBench.

Both Intel and AMD have the major disadvantage of having (or, let's say, wanting) to maintain x86 backward compatibility - which means not only staying compatible with the almost 45 year old CISC instruction set of the Intel 8086, but also with the whole line of CPUs that came after it. All this ballast makes it harder for them to build an energy-efficient CPU.

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.

Having to support x86 is definitely not a "major" disadvantage.

The X2 cores in 8cx gen3 get similar performance to Zen 2 U-series chips while using 7-10w instead of 15-50w.

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?

The competent people say that ISA doesn’t matter, so there’s that.

Do their actions match their words?

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.

When you're designing a new chip and working at a a fabless semiconductor startup, that doesn't mean you're free from corporate constraints. The most obvious is that if you design an ARM-based chip, the company has to pay royalties, and if you design a RISC-V chip, you don't.

ARM typically charges 1-2% in royalties. A company has to sell a LOT of chips for this to be the driving factor. In the case of a startup, we're talking about eliminating two entire teams costing tens to hundreds of millions per year and probably getting to market faster. You can sell a LOT of chips for even a small 100M R&D cost.

How about waiting until the competitors is actually on the same process node size until declaring the x86 baggage to costly? Most of all, Apple is currently in the lead because they threw money on TSMC to get a virtual monopoly on the smallest node size. How much of that which will remain once the competitors are comparable is an unknown at this point.

What if Apple maintains a lead in process mode though? 3 nm while Intel is at 5, 2 nm while Intel is at 3, etc. I’m glad they have competition from more than just AMD and wish all three the best.

Apple may maintain the lead, but it is done by throwing money at TSMC, not by having better technology by themselves. I'd prefer a situation where the TSMC let all of them have some access to the better node sizes as that would let the company with the better tech sell more.

I don’t see why the distinction would matter to the people it should matter the most to, Apple’s customers.

I was responding to a claim that Apple would keep their lead due to x86 baggage. It matters for the truthiness for that claim, it doesn't matter for how much stuff Apple will sell.

Comparing currently available CPUs on the market is pretty fair.

Sure, but would you go as far to claim that X phone is so much better in battery, Y has no chance of catching up, when X just put a twice as big battery in their phone?

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)

> 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

That is definitely true, but you can't reach any conclusion on the cost of the x86 baggage by comparing different process nodes. It has way too much influence on the end result to be ignored.

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.

A13 and Zen 2 were both made in TSMC N7 fabs, but the performance per watt differences were still enormous.

You have had the same fab processes for years on phone chips and Apple was winning every year. The fact the chip is in the chassis of a computer does not suddenly change the game in favour of AMD.

This argument goes back 30 years. As far as I know, not a hardware engineer, it's not that much of an issue since the only complicated thing is the decoder, and then it's microcode and not an issue.

The TSO memory guarantee X86 is probably the exception, since Apple supports it on their M1s too for emulation.

Do we know whether that x86 backward compatibility is all that problematic? If I’m not mistaken, it is only used as a “public API” even in current CPUs, and on a microcode level it doesn’t have as much relevance.

For example: Decode. One of the things Apple CPUs keep being praised for is how wide they are. To be wide effectively and keep your execution units busy, you need a wide decoder. With aarch64 it is easy. Every instruction is 4 bytes on a 4 byte boundary. Want a 4-wide decoder? Ingest 16 bytes and copy-and-paste the same decoder 4 times.

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.

Excellent answer. I learnt something today!

And those bytes matter when most Intel CPU cores have only a few dozen KB of L1I cache. Interestingly, the M1 and M2 performance cores have a whopping 192KB of L1 instruction cache.

Isn’t it in part due to business reasons, namely that Apple is not a CPU vendor, it doesn’t have to turn a profit on chips so it can allow much larger die sizes and thus larger cache sizes as well. Is there something inherent in ARM here I’m missing?

ARM instructions aren't as compact as their x86 counterparts, so they need a big cache to get similar performance on cache-bound applications.

AFAIK, AArch64 instructions are roughly 2x longer than x64's average, but that's 3x as much cache as a comparable Intel core.

ARM aarch64 instructions are around 12-15% bigger overall, but cache sizes are much larger than that. Most likely that is so they can power the massive reorder buffer and deal with having code for tons of branches handy.

That would be a dumb way to build a decoder. Which is why that's not how it works on x86 processors.

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.

> fetch an entire cacheline of instructions at once

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

> Something as simple and trivial as loading a 64-bit immediate into a register is a 10-byte instruction in x86...

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...

Did you even read what you linked to? This is atrocious decoding performance compared to arbitrarily wide aarch64

“

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.

“

The other answer was awesome but here’s another one: Number of registers.

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.

> 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).

Isn't that only used to support x86 emulation (i.e. apps for the older macs)?

Yea, and that emulation is fast as all hell !

Backwards compatibility costs a tremendous amount of silicon to handle the micro-decoding. The more problematic aspect is things like the segment registers from 16-bit x86, which can give you a 4-operand LEA, and other such nonsense. Sure, these operands can be microcoded, but that leaves a lot of performance on the table when a modern program wants to use an old instruction (SETcc comes to mind for branch elimination).

> Apple was able to just create a new CPU based on the much more modern ARM architecture

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

X86-64 INCLUDES all the legacy cruft of x86-32 and x86-16 and is thus 44 years old. Aarch64 in Apple chips doesn’t include A32 and is thus 11 years old. It is indeed a large age difference.

Apple was also the first vendor to ship an ARMv8-A compatible chip; I'm sure there have been reports that they heavily influenced the design of AArch64 but I can't dig them out right now.

To back this up, here’s a Twitter thread from an Apple engineer: https://twitter.com/stuntpants/status/1346470705446092811

> 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.

But ARMv8-A is backward compatible.

Armv8 aarch32 (32-bit) support is optional and hasn’t existed in Apple CPUs for years… (according to jail breakers and public SDK info). Aarch32 is a separate mode so dropping it is easy. In x86 you cannot drop 32bit because… it is part of the 64-bit mode and needed.

Apple dropped support years ago and the last couple ARM chip designs finally dropped support too.

A715 in particular made it's decoder 20+% wider while reducing die area by 75% all due to eliminating 32-bit support.

IIRC, you’re a bit wrong with the numbers. The decoder is now a fourth the size it used to be, and they’re now using 5 (up from 4).

It's more nuanced than that though 75% smaller is a fourth the size (I guess depending on where you're looking from).

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.

You should not consider the dates that support for these initial revisions had started, you should consider the dates it had been dropped. For x86, it's "never", unlike for modern ARM (see sibling comment).

ARM only officially dropped 32bit support last year.

https://m.gsmarena.com/arm_will_drop_32bit_support_in_the_bi...

...“in big Cortex-A cores.”

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.

afaik the last remaining 32 bit Apple SoC is in the Apple Watch Series 3.

> much more modern ARM architecture

ARM is nearly as old as x86 and has had just as many evolutions in architecture as x86.

But ARM didn't start out as a shitpile of attempted backwards compatibility with an 8 bit CPU. The i8086 was made as an evolution of the i8080.

And it's also not really "nearly as old" considering how fast stuff developed in the early day - the first ARM CPUs launched in 1986, and the i8086 in 1978 - 8 years earlier.

Yeah, the processor world changed a LOT in those 8 years. Specifically, Berkley RISC and MIPS were developed, which ARM was based on.

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

That still doesn’t make ARM “modern”.

No. The design made it modern.

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).

Classic ARM mode has been removed. Only ARMv8 is supported now.

The existence of 8086 instructions doesn’t slow AMD64 instructions.

It kinda does make the critical path in the decoder slower.

IMHO a major enabler for this is LLVM.

I think it's significantly reduced the time / cost / difficulty in rolling out a new instruction set architecture.

Are the GCC cross-compilers for ARM64 not sufficient? We're not talking about some niche, new architecture here like RISCV or WASM.

Rolling out a new architecture isn't just about getting your own tools out, it's about enabling the rest of the ecosystem to come along for the ride.

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.

I think it goes beyond LLVM, it's software in general. 20 years ago, software was locked into a particular architecture because proprietary compilers and binary blobs were the norm, and vendors still ruled their platforms with an iron fist. But nowadays, open source libraries and compilers are a lot more standard, and a lot of hardware/software is cross-platform so switching is easier. Linux is mainstream and gives you support for dozens of architectures for free.

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.

> Compare that to Microsoft's largely unsuccessful attempt of selling ARM-based Windows machines.

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).

> staying compatible with the almost 45 year old CISC instruction set

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.

An underrepresented point of view, certainly. As a software developer at a small game publisher, our idea of hell was a dozen incompatible platforms, none of which had a decisive advantage over the others, few of which could be ignored if the company were to prosper, and all of which were just different enough to tie up resources for porting that were badly needed for product development.

Wintel made a lot of good things possible that simply could never have happened in a fragmented market.

But you can run x86 software on the M1 at almost native speed through a software translator. Isn't that proof enough that the instruction set itself isn't what's holding back the hardware?

Most of the translation is done ahead of time, not something you pay for while running.

Very simple. There's also several articles discussing that how certain M2 configurations are actually lower performance than the M1, so this is hardly a done race.

> achieves 87% of the performance of the Intel 12900K and Nvidia RTX 3090 combined

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.

Also, just stumbled upon this recent video[0] taking on the Apple marketing/graphs for the M1 ultra and testing their claims.

[0]: https://www.youtube.com/watch?v=jCs27cNz6_k

I dont fall in the "apple has changed the world" camp, but bear in mind what you're saying here - the flagship $1500 MSRP GPU is less than an order of magnitude quicker than a $2000 (total) device, with less than half the power usage. That's a pretty impressive feat for a first attempt.

> is less than an order of magnitude quicker than a $2000 (total) device

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.

I am not saying their chip isn't impressive, just that they are clearly lying/deceiving in their marketing.

> the flagship $1500 MSRP GPU is less than an order of magnitude quicker than a $2000 (total) device

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.

You're right sorry - I accidentally compared the price of an M1 Pro instead of an M1 Ultra.

I mean, the top and bottom GPUs of any generation differ by much less than 10x the performance but do differ by 5-10x the price. The 3090 is $1500 while the 3050 is $250 so 6x the price. The 3090 is only 2-3x the performance of the 3050.

There's large diminishing returns as you push performance to the utter maximum.

But can it run Crysis?

Apple is pretty much a no go for gaming.

> But can it run Crysis?

Yes?[1]

[1] https://www.paulthetall.com/crysis-for-mac-osx/

No disagreement on that, but that is a very complicated topic. It's not _just_ a hardware problem on Mac, there's also the OpenGL/Vulkan/Metal debacle, and lack of audience compared to windows for developers to target. There are more using steam with windows 7 than steam on Mac [0]

[0] https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw...

It wasn't their first attempt. Apple has been making chips for their phones for years.

There's a huge difference between mobile and desktop chips. They have very different constraints. As I said, I'm not in the "apple have changed the world camp" but they have managed to bring high end desktop performance at laptop level power usage, that also sustains output.

1. Apple literally pays billions to TSMC to build a new fab

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

Then why was Apple winning against every other phone chip before they got access to 5nm? The M1 is the first time Apple has had exclusive access to a node in its decades plus history of making chips, and yet it has had the fastest chips for a decade.

For many years, AMD GPUs were cheaper and equally or more performant than NVIDIA GPUs. Did that stop NVIDIAs lead in AI training? No, software support is the key component.

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.

"For many years, AMD GPUs were cheaper and equally or more performant than NVIDIA GPUs. Did that stop NVIDIAs lead in AI training? No, software support is the key component. 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."

Riiight, but, OP isn't necessarily talking purely from an AI/ML use case.

Well if you don't need the high performance, then I'd expect people will go for a cheap CPU, meaning no M1 Ultra.

ML training isn't the only application of high performance computing. Apple is making video editing machines - which is why they have the mix of cores that they do. Simulations are also high-performance computing applications.

> Apple is making video editing machines - which is why they have the mix of cores that they do.

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.

Software changes much faster these days. We are all dealing with high abstraction layers and legacy x86/64 and even CUDA can be replaced without much disruption in most cases.

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.

"even CUDA can be replaced without much disruption in most cases"

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.

iirc there are comments saying that ROCm is not very mature yet. I wish OpenCL can evolve to compete with CUDA

Is that more an indictment of ROCm immaturity or of PyTorch/TensorFlow unwillingness to support it?

I believe ROCm isn't usable yet.

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.

It is the former, that Nvidia effectively sponsors ML libraries. If you're training a neural network, and you are hiring expensive ML people, you're likely just going to pay the Nvidia tax than work on ROCm support.

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.

> building a GPU-capable BLAS library is just a lot more work than one would think

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.

DirectCompute is only the execution of fully trained neural networks, so they can skip all the gradient calculations, which are the compute-heavy and memory-heavy part.

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)

DirectCompute is pretty close to CUDA. When handled with care, it can do these compute-heavy pieces with similar performance.

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.

ROCm is pretty mature, but harder to support than CUDA. Its BLAS library works well. PyTorch and TensorFlow are likely getting a lot more help from Nvidia than from AMD on compatibility. The ROCm ecosystem is a lot smaller, too, so there are many fewer examples to copy.

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.

In our case, we train on NVIDIA and then port to C++ with AVX. It's a bit more work, but deployment on AMD CPUs is even cheaper than on AMD GPUs.

> It's the same with Apple's M1. I don't know anyone who is using 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.

Yes, but the reasons are to do with business and investment as much as technology.

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.

* presumably Qualcomm and not Cisco, for mobile SoCs?

100%; the business model side is the major advantage Apple has here. Part of that advantage is the sheer size of the market compared to desktop/servers. They will sell 10s of times more CPUs for iPhones/Macs than anyone will sell for servers/desktops. I am less optimistic that anyone else can compete, since no one else seems to be able to straddle both markets and use scale across both.

> Apple utterly dominates the mobile phone CPU landscape,

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.

I read “dominates” as has the “dominate share of the profits for the industry”. Not dominates shipments.

By that metric Microsoft utterly dominates the web server market.

Yes, but that's not the point here. I don't know what Microsoft does with their IIS profits but Apple is definitely reinvesting them back into making better phones.

> I don't know what Microsoft does with their IIS profits

That's ok. Microsoft doesn't either ;)

The point is that you've chosen a questionable benchmark that is only correct if you adopt a very spwsific point of view.

I think the @simonh "domination" point is that Apple has dominated the mobile phone CPU PROFITABILITY landscape, not the SALES landscape, and I for one feel @simonh has a valid point.

To emphasise, according to Counterpoint Research as of last year (https://www.counterpointresearch.com/global-handset-market-o...) Apple is able to maintain 75% of the total profits on the phone market, while Samsung only captures 13% and others (including Xiaomi and the BBK group) capturing the remaining 12% with no single company peaking above 5%. Apple could store two-thirds of its profits offshore (waiting for an opportunate tax break) while only moving a third of that profits into actual use and it will still be better than Samsung's position.

(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.)

If you're talking about CPU profitability, then look at Qualcomm profits, not Xiaomi.

I read that as mobile CPU performance is where Apple dominates. And they do. This is why people have been wondering for years when Apple would put one of their mobile chips (or a derivative) in a laptop.

> That seems to be an interesting definition of "dominates". 14% of global smartphones from independents.

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.

I'm sorry but I have to label this as a bad-faith attack. "dominates" in this context means being the fastest available, not necessarily that most people will buy that. It's like saying "the i9/Ryzen 7 dominates" and then answering with "most people buys Celerons/Athlons". You need to read the context of the conversation: it is about performance domination and not usershare domination.

And yet this subthread is filled with several people who have yet a 3rd (maybe even a 4th) interpretation. I don't dispute that yours could be the intended one, but let's not pretend that it's completely clear.

The iPhones are not always the fastest and certainly not dominating.

The thread is about performance and technology, and Apple dominates the phone CPU landscape in those areas. I thought that was clear as my comment mainly addressed technology and the driving forces behind it, but I’m sorry for the confusion.

Maybe commoditizing and refusing to differentiate your products, merely being content to shove the pablum OS everyone uses is a mistake?

Intel is investing in RISC-V[0] as well as working on its own chips.

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...

> I don't see Apple taking on server markets, where the power per watt is perhaps less important.

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.

In general what I see as a massive issue for ARM and big win for x86 is standardization (or in case of ARM lack of)

- 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.

Can there be a software side compensation for this lack of standardisation? Because I too don't see any hardware standard coming very soon to ARM and I don't think it can even.

But, maybe there can be a build automation which can handle all the hassle and minimize the randomness?

I thought user-space applications should be fine? Bootloaders that kind of stuff has to deal with low-level interfaces and those do differ from SoCs to SoCs.

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....

Almost nobody actually runs ARM in big-endian. I suspect although the ISA is technically capable of endian switch many SoCs wouldn't even work in BE.

I seem to recall trying to get uboot and and RPi to boot big endian at one point and it was infeasible.

That used to be true, but ARM has been standardizing these aspects now for a long time. Modern ARM systems can use ACPI for example.

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.

Performance isn't everything.

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.

The main reasons to have that power certainly are not gaming and VR. A computer is a tool for work as well as leisure. For artists, editors, programmers, scientists, etc. more power means less time sitting around waiting on a render, build, simulation, or export. Apple aren't making these chips for gamers lol.

Reading this thread, the delusional thinking is thick!

I’m hearing that we need to wait until Intel moves to 5nm to really compare. When that means that the whole PC market cedes the crown to Apple, who is not slowing down. Apple is on its second generation on 5nm and the x86 crowd as yet to show any response!

That it’s only because Apple is on 5nm that they’re competitive. Which is crazy, since we can directly compare slightly older chips made on a 7nm process and Apple comes out way ahead.

That the competitors like Qualcomm are not optimizing for performance. When the reality is much simpler. The benchmarks are this bad from Qualcomm because they’re optimizing for their wallets.

The reality is simple: for a decade, Apple has had the fastest phones, and the fastest tablets. Are you PC guys ready to admit Apple has the fastest computers?

Your comment is needlessly argumentative. No one is saying they aren't good chips.

Also if it isn't the process it arguably makes it easier for them to catch up because other than the semi-cultural stuff like EDA tooling changing a design is much easier than changing a process.

Now they have a real target to hit I expect the gap to close, especially if Intel can convert their IDM concept into a real battle with TSMC

"Qualcomm Confirms Nuvia Arm Chips Will Be in PCs by Late 2023"

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."

Qualcomm has been "on track" with desktop level chips based on their mobile platforms for at least four years. I've tested the first Windows on Arm laptop with a series 8 "desktop" Snapdragon in 2018. Yet, they still have to ship anything meaningful. They lake the vertical integration Apple has, and they will never have it. Hard for me to see how competitors (Qualcomm + Microsoft + OEMs) are supposed to go after Apple in this area, considering how incapable they are at working together in a productive way.

> are supposed to go after Apple in this area,

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]

Doom and gloom for Apple is a common way to get clicks. The M2 in many workloads looks like ~20% increase which is certainly not a slowdown for YoY performance. Additionally, everyone is alway 2 years out from beating what Apple is selling today, ignoring where Apple will be in 2 years.

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.

How could we define a slowdown or speedup in YoY performance improvements, for the M2? It is the first successor.

Despite the M1 moniker, Apple has been doing in-house silicon for about 7 generations now - they started with A7 iirc, and M1 is part of the A14 generation, and M2 is part of the A15 generation. M1 is what would have traditionally been called an "A14X", meaning wider GPU than the phone-sized SOC. So there are basically 8 generations of YoY comparisons to make.

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.

Sure, but since they've moved into an entirely different class of device, I don't think the A<n> series establishes a very useful baseline. I mean, scaling the phone/tablet type chip up to laptop/desktop class must have made them bump into some bottlenecks that previously looked infinitely wide. Depending on how difficult those bottlenecks are to clear, we could see some years with quick progress, some years with not so much.

> More recently, SemiAnalysis broke the news about Rivos Inc, a new high performance RISC V startup which includes many senior Apple engineers.

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 CPU Gains Grind To A Halt

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...

8cx Gen 3 (using ARM X2) performance in early benchmarks puts it (for the first time) around Zen 2 in performance while using a fraction of the power (anywhere from half to 5x less power under load and even better metrics at rest).

Qualcomm got impatient and entered too early causing people to write them off.

Their problem has never been technology or talent, just the fact they care a lot more about the margins they make on those chips.

The newest snapdragons have had gimped cashes for years now.

> Late 2023

>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?

The M1 is packed to the brim with top of the class technology (lower node, big ROB, big caches, fast buses, very complex prefetching and branch prediction...) and has the advantage that it was basically wrote from scratch during a decade or so from simple mobile level processors to full grade CPU, but it is not magic. Competitors can certainly catch up in some years

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.

This isn't the first time there's been a shift in claims to the various performance thrones and it certainly won't be the last. It might take a while before there's another king on the CPU with integrated GPU throne, but someone will catch up eventually.

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.

Apple Silicon:

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.

Considering that no one with an apple M1 chip is gaming or training ML with it, I'm not even sure what it means that these are supposedly better. What are people even using the extra performance for? Keeping thousands of tabs open simultaneously?

We use it for compilation. The M1 Mac Pro we use is about 50% quicker than the i7 we had before it for an end to end compile of our project.

Compilation is just fast for me. A 100% increase in speed won't make a real difference. (Except when I compile an entire project from scratch, which I almost never do.)

I work on a medium sized project. A full rebuild is about 25 minutes on the M1 Mac and was about 55 minutes on the i7 Mac mini we used before. The "normal" build (what most developers have to face semi-regularly) is about 15 minutes on the Intel and about 4 on the M1. (I checked our CI numbers and can't explain the discrepancy sorry but I would guess the M1 Mac is quicker linking and the link time dominates).

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.

Audio and video production, and web and app development.

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.

> Considering that no one with an apple M1 chip is gaming or training ML with it,

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.)

Given that whatever Apple has is not going into 80% of the desktop market, 60% of the mobile market, 100% of game consoles, or 100% of the server market, it matters much less than some Apple afficionados make out of it.

When Apple can make a game console for half the price with the same GPU power as the competition, which is something that could happen in ten years, Microsoft and PlayStation are going to sweat and pay very close attention to what Apple is doing.

Does Apple make anything at half the price of a competitor? Nothing is impossible in the future but past behavior indicates that an Apple console would likely not be "half the price". Also, Apple has sometimes been considered a "luxury" brand in tech, and that probably also means it's unlikely to push a reduced price console without diluting the brand or their image.

If they make it for half the price, they won't sell it at that price. They'll make sure to make a hefty margin on every console sold. Realistically, Apple will stop putting old phone chips in its TV box, and they'll start putting the more recent chips with good GPUs.

Good luck with that. Remember Pippin.

How can the Pippin relate to any future console endeavour of Apple? I can't think of any piece of tech, or employee, who was there when the Pippin was released.

Lack of understanding of game development culture.

You can also look into Apple Arcade on Apple TV to see how current culture plays out.

Their golden eggs for game developers is the iOS, thanks market share on mobile platforms.

Don't mix that with living room culture from consumers and content providers.

I hope so, but I'm also sure.

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.

Apple will stay in the lead as long as they pay TSMC for a virtual monopoly on the smallest die sizes. How it will look when that situation changes is anyones guess. Apple is likely to continue to use the least electricity as they have spent a lot of effort on that, but other than that is impossible to say.

I don't think there is a technical reason why a chip based on the x86 ISA could not be just as efficient as one based on Apple's ARM-variation.

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.

I would imagine that any implementation of x86 would have to bear the weight of reverse-compatibility. With reverse comparability, the bad design decisions just compound, for example complicated stuff like memory synchronization https://youtu.be/KeLBd2EJLOU?t=2956

Exactly. I wish it wasn’t the case, but x86 compatibility will always come at a cost, in particular due to memory semantics, but also I believe due to its complex ISA requiring more silicon.

It would have been a critical factor if this was circuits with a few thousands transistors.

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

And then you try gaming and it is comparable to a Ryzen 7 4800H (45W)/ Nvidia GTX 1650ti (50W).

Several versions of M1 and M2 GPU’s but M1 8-Core GPU (15W) being roughly equivalent to low end 50W GPU’s makes me want to see what Apple could do with a discrete graphics card.

10+ times M2 performance as a discrete 200W card with dedicated memory and 100ish cores could be really compelling depending on the price point. That’s RTX 3090 territory, but much easier to cool etc.

The biggest problem has been Metal and incompatibilities. Metal 3 brings most of the important things they've been missing. We're already seeing companies like crossover working on this to make a lot of additional games work on their hardware.

The second issue is dev relationships. The real AMD/Nvidia advantage over other GPU makers is that they pay huge amounts of money to optimize games to the point that their drivers will detect a game and then completely replace huge sections of the game with optimized versions they wrote. These relationships take a lot of time to establish and maintain.

In any case, supply chain rumors strongly indicate Apple launching a very expensive VR headset in 2023 (which also matches up well with games that would be delivered after a half-billion dollar investment into their gaming subscription service around 2019). There are also rumors of Apple making an offer to buy EA games.

Apple makes more money from games than every other major game company put together. They have a huge interest in moving further this direction going forward. I don't see any way they don't just throw large amounts of money into this problem until it goes away.

Perhaps the competition will instead come from China. Xiaomi, OPPO both make their own chipset now.

No worries, next president will just ban them.

I think they are quite aware of that.

China has their infamous five year plans and for 2025 they have a goal of suppying 70% of their own semiconductor demand.

So it is pretty much given that we will see high-end Chinese CPUs by then.

Good luck with that if you cannot get the latest chipmaking machines from ASML. There is basically no competitor to ASML for latest gen chipmaking machines.

https://www.reuters.com/technology/asml-still-has-no-licence...

Yes. This is the heart of the tech war.

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.

ASML is banned to sell the newest machines to China so I don't think it will happen soon.

https://www.reuters.com/technology/asml-still-has-no-licence...

the main issue IMHO is that competitors are not choosing the right combination of cores and peripherals when designing SoCs. Apple is doing that much better.

for example i am not interested in 2x an A53 and 2x an A72. i want an octa core with the fastest A cores available. each time when i tried to find that i ended up in the server processor world with a price tag to match.

stuff like 4k video decoders and TPUs are of no interest to me. yet multiple i2s ports or TDM are missing on typical mobile SoCs.

AMD has some seriously interesting CPUs these days but unfortunately it seems hard to get access to parts if you are a small time device manufacturer…

I think if x86 get rid of their legacy instructions, they could reduce their core size, and a few side effects will be performance per watt gains and maybe also performance (smaller cores), and if you need the legacy instructions you could just emulate, most consumer PCs don't need those.

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).

> I think if x86 get rid of their legacy instructions, they could reduce their core size

Aren't those legacy instructions already emulated in microcode? I don't think they take up much physical footprint.

Yes. People bandying about "legacy x86" instructions miss this often. This isn't much different, conceptually, from Apple's Rosetta, except it's provided in microcode automatically rather than a discrete transform you need to run once and cache. This is very convenient for broad x86 backwards compatibility (e.g. I can run a Java 1.4 JVM and StarOffice or a libc.so.5 to play Unreal Tournament 2004 just fine on my 5900x). Can I run x86 apps, even ones from the last couple years on an M1 with no questions asked? Well, we abandoned local dockerized development at work because Docker for Mac's qemu couldn't hook into Rosetta and qemu alone couldn't handle JIT'd instructions from a jvm11[0]. Maybe that changes with the new MacOS version and the next version of Rosetta (there seems to be a Rosetta that works like qemu's binfmt_misc translators for Linux), but it's been missing for 2 years so far and caused me to do a bunch of work on remote dev capabilities in the meantime.

[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.

Do you really target the Java 1.4 JVM?

No, but I used the Java 1.4 JVM to run StarOffice for compatibility with an old document that had no other reader within the last three months. I did this from my AMD Ryzen 9 5900x running Linux.

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.

Modern x86 processors use about 10% of their power budget for instruction decode (translate variable-length x86 machine code into one or more fixed-length microcode instructions and remap registers). The primary modern benefit of this setup is that the decode logic can optimize code at the cost of power.

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.

X86 will always be slower because it has stricter memory ordering semantics.

Not really an issue under most usage scenarios. x86 suffers mostly from the cost and complexity of the decode unit. Once decoded instructions are cached, the performance penalty mostly disappears.

Ordering semantics (TSO) that Apple's M1 implements.

I guess it should be slower too?

M1 implements TSO as a special mode specifically for x86 compatibility: https://github.com/saagarjha/TSOEnabler

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.

And it is a LOT slower to run rosetta apps instead of native ones despite all the silicon thrown into emulation.

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.

Apples hardware is proprietary and they don’t offer or probably plan to offer server chips. I think what would make these stats more interesting is if we saw a shift in the thin client vs. fat client debate back to fat clients. Perhaps these changes will bring us into that era?

Amazons arm-based offerings are pretty interesting as are the other non-x86 initiatives. But I don’t see x86 going away in my day job any time soon.

You are so wrong about achieving 87% of rtx 3090 power.

If your views on technological progress are informed by the 80s and 90s, and you think it is an exponential curve, then it seems unlikely that today’s leaders will ever be caught.

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.

Past performance is not indicative of future results

Seismic shift? Seems to be pretty much on-par with current AMD and Intel offerings [1]. Let's see how Apple holds up when AMD gets on the same node.

[1] https://www.youtube.com/watch?v=FWfJq0Y4Oos

The GPU is not that fast. It is at heart a mobile architecture that excels when the application takes that into account. Otherwise, it is mediocre. It is also worth noting that performance does not scale linearly with power. You can often get something like 75% of the performance at 50% of the power.

He who is first will later be last

Bob Dylan

And the first one now will later be last - Bob Dylan

The last will be first, and the first last - Matthew 20:16

Imho they can as long as they agree to drop some sort if retro-compatibility.

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)

> Imho they can as long as they agree to drop some sort if retro-compatibility.

What's the performance hit/wafer space for that today?

I've heard numbers like 5-10%.

>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

Not really. Most of the legacy instructions are implemented via microcode anyways, so the amount of resources dedicated to legacy support is minimal.

Of course. It's not a seismic shift; it has some advantages in some dimensions.

Can HN users see there's more nuance to performance than marketing jargon?

And yet slack still takes 30 seconds to select and load a chat.

Apple fans sure love pretending other chips are as slow as they are

> 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

Well, I dont think there's need for a personal attack here. Even though they might not be 87% faster, they are still quite significantly faster for an ultrabook and they do deliver the battery life. So I guess the OP's question can be taken as, could intel or amd or OEMs achieve the performance to power ration soon ?

This is precisely the right reformulation of the actual question.

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.

Yes, but the performance/power is extremely important for laptops. As a long time Linux user I'm seriously considering migrating to Mac just for the laptop staying cool and silent after hours operating on battery.

> Well, I dont think there's need for a personal attack here.

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."

What are your sources for these claims? A quick googling led me to https://www.tomsguide.com/face-off/microsoft-surface-laptop-..., and there they clearly state that the MBP has both better battery life and performance.

That is the Surface Laptop Studio, a different computer than the one that I named

Do you have any links to the articles that you are referring to?

Your gpu perf numbers are not representative.

Well if the initial M2 machines are anything to go by then x86 really has nothing to worry about. Apple will damage the reputation of their systems by themselves.

The question is "Would they, and do they need it?"

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.

> 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?

Yes, otherwise they wouldn't have gone into own chips with such low volumes. Even now their volumes probably don't afford for them making much money on such big chips if we compare them to top tier competitor SoCs.

Most of the performance advantage of Apple silicon is that it puts CPU, GPU and all memory (that is typically VRAM and DRAM in traditional architectures) millimeters from primary DRAM. When competing purveyors start do this with their own clever packaging, they will start to approach Apple’s mips/watt.

Emulation on M1 is outstanding. The spatial locality of main memory nullifies emulation penalty. Apple has come close to what Transmeta tried to do.

Nope. There's little or no advantage to 2 mm vs. 20 mm.

When multiplied over billions of clock cycles it makes a tremendous amount of difference.

There's a reason why PCB board specs say that all DRAM traces need to be the same length - the length of the trace, and it's capacitance are the main speed limiter for any signal. This is true whether the trace is 20 mm long or 2.

"the critical point to DDR circuitry is in the timing. This means that the clock lines will determine the timing of the input and output of the memory chip data lines. Electrical signals can not be sped up, so the only way to control the timing is to add length to the traces in order to delay the arrival of the clock signal. This is accomplished by adding serpentine routing to the trace routing."

https://resources.pcb.cadence.com/blog/2019-ddr-routing-tech...

"So the physical RAM modules are still separate entities, but they are sitting on the same green substrate as the processor. “Big whoop,” I hear you saying. “What’s the big deal?” Well, first of all, this means faster access to memory, which inevitably improves performance. In addition, Apple is tweaking how memory is used within the system."

https://www.howtogeek.com/701804/how-unified-memory-speeds-u...

Reply on news.ycombinator.com