No, they’re using their own designs for AmpereOne, and all chips going forward.
The real hubris at these companies is thinking they can build a team that can create a better chip in one generation. Apple is on what the 10th public generation of their own cores, from a team they acqihired that was already producing cpus? How many generations/respins did it take before they replaced the ARM ip with their own designs, and then how many generations was it before they were faster? Not only that but Arm seems to have gotten serious a few years ago and the IPC is within striking distance of the best amd/intel products. They are no longer doing obviously stupid things, so it seems odd a company like ampere doesn't have another respun Altra with a N2/V2 sitting on the sidelines as a fallback when their own design fails.
The specs there sound seriously impressive to me, and like they might be getting ready to leave AMD and Intel behind in terms of IPC (for their highest performing chips).
ARM's clock speeds are much lower, so single core performance will probably be worse. But I'd guess server clock speeds may be similar.
Disclaimer: I don't know what I'm talking about
Note that dispatch doesn't mean vector width, which is harder for software to take advantage of. It means how many uops the pipeline can handle/clock cycle.
As for higher clock speeds, there's a whole lot more that matters such as pipelining instructions, cache sizes, and any number of other things. Clock speed by itself isn't particularly revealing.
I would also not expect the X4 to utilize that full width in any real workload, but it only needs a fraction of its full width to get more IPC than the X64 competition.
But I'd expect it is a reasonably balanced chip (why waste silicon?), and thus the wide pipeline is an indicator of the chip itself being wide with immense out of order capability.
Branch prediction rates tend to be extremely high. The X4's frontend also has 10 frontend pipeline stages. Which means ideally, it'd be correctly predicting all branches at least 10 cycles into the future, so that on clock cycle `N-10`, the frontend can get started on the correct instructions that'll be needed on clock cycle `N`. The difference between 1 basic block/cycle and >1 basic block/cycle is really small; it already needs a long history of successful predictions to get 1. But of course, each mispredict is extremely costly.
As for bringing up clock speeds and the M1, my point there was that the M1 has already left Intel and AMD behind in terms of IPC; it achieves similar performance despite much lower clock speeds. My original comment said that the ARM Cortex X4 looks like it is starting to leave Intel and AMD behind in terms of IPC, and I used the width as an indicator. You responded saying that the software has to actually allow for this. Yet the M1 example shows that existing software does in fact allow for significantly more out of order execution than Intel and AMD CPUs achieve.
So you could argue that, unlike the M1, the Cortex X4 will not be able to realize such an advantage. While plausible, if it does fail to do so, we at least won't be able to blame the software, because the M1 is able to do so despite the software. It'd have to be some deficiency of the X4 relative to the M1 -- such as cache sizes, memory bandwidth... Hopefully it does turn out to be a great chip! But that remains to be seen.
> Yet the M1 example shows that existing software does in fact allow for significantly more out of order execution than Intel and AMD CPUs achieve
My point is, shortening the pipeline needed to execute an instruction would also get higher performance. Perhaps they invented a better cache, perhaps larger, perhaps more associative, perhaps…? There's more than one way of increasing performance besides IPC and clock.
Design of the CPU can also influence all three of these. Things like better cache, better branch predictors and shorter pipelines, will all help IPC.
> My point is, shortening the pipeline needed to execute an instruction would also get higher performance.
This wouldn't increase throughput if 100% of branches are predicted correctly -- except for the the extra cycles before instructions start executing. It'd decrease branch mispredict penalties though, which is a big deal and would help in practice. The Cortex X4 did shave off a frontend pipeline stage relative to the Cortex X3 (11 -> 10). This is better than Intel Alder Lake. One contributor is probably that it is easier to decode ARM instructions in parallel without needing mutliple pipeline stages (e.g., one to find out where variable width instructions end before the instruction byte stream can be sent to decoders [not an issue if instructions are already in the uop cache]).
> There's more than one way of increasing performance besides IPC and clock.
I assume by "IPC" here you mean dispatch width? Things like a better cache for fewer misses, better prefetching, better branch prediction, larger reorder buffers so that it can speculate further ahead before stalling, all help IPC.
Zen1 CPUs (6 uops) were already wider than Intel Skylake (4 uops) and Ice/Tiger lake (5 uops), matching Alder Lake (6 uops). But they were obviously far behind in IPC (and Zen1 in particular also decoded AVX2 instructions into 2 uops).
Zen1 has SMT, which was part of the reason to go wide early on: the frontend wasn't good enough to feed that width with a single thread, but using two threads could mitigate that. Early on, Zen1 (and the Zen family) generally did better in multithreaded than single threaded benchmarks thanks to that approach.
The ARM Cortex X4 doesn't have SMT, so it's taking a different approach to performance.
A single number isn't going to be representative of performance across benchmarks or all the tasks you're interested in.
Unfortunately, I think it'll be more than a year before we can see the Cortex X4 (as it's aiming at TSMC N3E), but I'm definitely looking forward to deep dives into it's performance (and also that of Intel's Meteor Lake, Zen5, etc).
Apple doesn't do it with ARM design in this sense.
[0] https://www.macrumors.com/2023/02/22/apple-secures-tsmc-3nm-...
But I thought we were talking Server/Desktop chips, not phone chips (I have no clue about them, my MI11Ultra seems fast enough for everything, I'm not compiling on it).
And the M2 has massive caches (L1/L2/L3) https://en.wikipedia.org/wiki/Apple_M2
How much performance you get with caches are shown with the X3D models that - gaming performance - are faster than all than more expensive Intel/AMD chips.
M2 Max Ryzen 7900
Cores 12 12
L1 320kb 64kb
L2 32MB 12MB
Last 48MB 64MB (32MB/chiplet)I do expect Ampere to succeed in outperforming stock ARM core designs. Otherwise, there'd be no reason to have embarked on a very risky and expensive journey to have their own custom cores.
They're doing it because they THINK they can outdo Arm.
Arm isn't standing still, and they would have had to start years ago.
And in the Datacenter you've also got google and Amazon making their own arm based chips, not sure if MS does the same.
However, Apples M1 Chip had the biggest impact to consumers I think. The tensor chips aren't particularly better and we just don't have any interactions with hardware servers
AWS used Neoverse for Graviton.
Google Cloud is designing their own ARM chips: they're working on one design from Marvell (likely Neoverse), and their own custom design. These are in the design phase, and very unlikely to be produced this year.
Re: Google Tensor chips on phones: Those used ARM Cortex CPU and ARM Mali GPU, and a Google designed Tensor processing unit for machine learning. The google TPU replaces chips like Qualcomm Hexagon. The TPU does not use an ARM instruction set.