Hacker News

ARM Cortex-X925 achieves indeed a very good IPC, but it has competitive performance only in general-purpose applications that cannot benefit from using array operations (i.e. the vector instructions and registers). The results shown in the parent article for the integer tests of SPEC CPU2017 are probably representative for Cortex-X925 when running this kind of applications.

While the parent article shows AMD Zen 5 having significantly better results in floating-point SPEC CPU2017, these benchmark results are still misleading, because in properly optimized for AVX-512 applications the difference between Zen 5 and Cortex-X925 would be much greater. I have no idea how SPEC has been compiled by the author of the article, but the floating-point results are not consistent with programs optimized for Zen 5.

One disadvantage of Cortex-X925 is having narrower vector instructions and registers, which requires more instructions for the same task and it is only partially compensated by the fact that Cortex-X925 can execute up to 6 128-bit instructions per clock cycle (vs. up to 4 vector instructions per clock cycle for Intel/AMD, but which are wider, 256-bit for Intel and up to 512-bit for Zen 5). This has been shown in the parent article.

The second disadvantage of Cortex-X925 is that it has an unbalanced microarchitecture for vector operations. For decades most CPUs with good vector performance had an equal throughput for fused multiply-add operations and for loads from the L1 cache memory. This is required to ensure that the execution units are fed all the time with operands in many applications.

However, Cortex-X925 can do at most 4 loads, while it can do 6 FMAs. Because of this lower load throughput Cortex-X925 can reach the maximum FMA throughput only much less frequently than the AMD or Intel CPUs. This is compounded by the fact that achieving better FMA to load ratios requires more storage space in the architectural vector registers, and Cortex-X925 is also disadvantaged for this, by having 4-time smaller vector registers than Zen 5.

In my view, power consumption isn't relevant to a desktop or workstation (and increasingly, desktop machines are workstations since almost everyone uses laptops instead). When I'm plugged into a wall socket, I will take performance over efficiency at every decision point. Power consumption matters to the degree that the resulting heat needs to be dissipated, and if you can't get rid of the heat fast enough, you lose performance.

That's a possibility. Some code still assumes (without realizing!) x86 style ordered loads and stores. This is called a strong memory model, specifically TSO, Total Store Order. If you tell x86 to execute "a=1; b=2;", it will always store value to 'a' first. Of course compilers might reorder stores and loads, but that's another matter.

ARM is free to reorder stores and loads. This is called a weak memory model. So unless it's explicitly told to the compiler, like C++ memory_order::acquire and memory_order::release, you might get invalid behavior. Heisenbugs in the worst case.

I think that's less likely than you'd expect because the memory ordering model used by C++ and others essentially requires you to write code that works even without x86's total storage order. If you don't then you can get bugs even on x86, because the compiler will violate the ordering you thought you had in your program, even if the CPU doesn't.

Also most software runs on ARM now and I don't think that has actually happened in practice.

The major issue is these days most software is electron based or a webapp. I miss the days of 98/XP, where you'd find tons of desktop software. A PC actually felt something that had a purpose. Even if you spin up a XP/98(especially 98/2000 VM) now, you'd see the entire OS feels something that you can spend some time on. Nowadays most PCs feel like a random terminal where I open the browser and do some basic work(except for gaming ofcourse). I really hate the UX of win 11 , even 10 isn't much better compared to XP. I really hope we go back to that old era.

This is actually one reason I feel like developing my systems level stuff on ARM64 instead of x86 (I have a DGX Spark box) is not a bad idea. Building lower level concurrent data structures, etc. it just seems wiser to have to deal with this more immanently.

That said, I've never actually run into one of these issues.

If it is programmed in assembly. This kind of nasty detail should be handled by the compilers.

Wouldn't the compiler take care of producing the correct machine code?

If you go around your OS yes that could be the case but you can already have issues using the application from machine to machine with the same OS having different amounts of RAM and different CPU's. But I am not an expert in these matters.

Only for the hand-written assemply parts of the source code. The rest will be handled by the compilers.

That would only matter (to me, at least) if those Apple chips were propping up an open platform that suits my needs. As things stand today, procuring an M chip represents a commitment to the Apple software ecosystem, which Apple made abundantly clear doesn't optimize for user needs. Those marginally faster CPU cycles happen on a time scale that anyway can't offset the wasted time fighting MacOS and re-building decades-long muscle memory, so thanks but no thanks.

Those are of almost zero use for people wishing to run Linux etc.

Yes, Asahi exists, and props to the developers, but I don't think I'm alone in being unwilling to buy hardware from a manufacturer who obviously is not interested in supporting open operating systems

Apple does not produce general purpose computing parts.

This is an industry blog, not a consumer oriented blog.

Same, I wish Chips and Cheese would compare some of these cores to Apple Silicon, especially in this case where they're talking about another ARM core.

A few years ago they were writing articles about Apple Silicon.

It does make me miss the deep dives for new core designs from Anandtech.

Running the SPEC benchmark interger and floating piitnt suites takes all day, but it's hard to game a benchmark with that much depth.

It's a shame that nobody has been willing to offer that level of detail.

Chips and Cheese focuses on architecture and chip design, and I think a lot of the tooling is less refined on macOS, so the comparison graphs can't quite get the same depth on Apple's chips. That's just a guess.

But I did some comparisons when I tested the same Dell GB10 hardware late last year: https://www.jeffgeerling.com/blog/2025/dells-version-dgx-spa...

They are talking specifically about ARM cores designed by and licensable from ARM Holdings (the company), not other designs that don't use ARM's designs (like the Apple silicon).

>Kind of weird to see an article about high-performance ARM cores without a single reference to Apple

And Qualcomm.

Kind of weird that you pick Apple CPU cores when Qualcomm cores would be a far more appropriate comparison.

The core they're talking about was released about two years ago. nvidia stuck it on their grace blackwell (e.g. DGX Spark) as basically a coordinator on the system.

Anyway, here it is in GB10 form-

https://browser.geekbench.com/v6/cpu/14078585

And here is a comparable M5 in a laptop-

https://browser.geekbench.com/macs/macbook-pro-14-inch-2025

M5 has about a 32% per core advantage, though the DGX obviously has a much richer power budget so they tossed in 10 high performance cores and 10 efficiency cores (versus the 4 performance and 6 efficiency in the latter). Given the 10/10 vs 4/6 core layouts I would expect the former to massively trounce the latter on multicore, while it only marginally does.

Samsung used the same X925 core in their Exynos 2500 that they use on a flip phone. Mediatek put it in a couple of their chips as well.

"Reaching desktop" is always such a weird criteria though. It's kind of a meaningless bar.

Perhaps you're not the target audience of the article.

Apple doesn't expose the kind of introspection necessary to compare with the data the article is about. Any mention would just be about Apple's chips existing and being better

You make a valid point; Apple has indeed set a high standard for ARM cores in performance. A comparison with their M4 and M5 cores would provide valuable context for these new developments.

We should have N1X vs. X2 vs. M5 laptop battery life reviews in a few months.

Nor do they say what process it's fabricated with.

The C1 Ultra looks really powerful. 128 kb L1D cache on it's own is a ~10% IPC improvement that should let it pull firmly ahead of the x86 competition which is very stuck at 32kb due to the legacy 4k page size.

Why would you not be able to build a PC around it? That's what you do with PowerPC.

> ARM designs are effectively paper launches. You get these press releases saying the new ARM matches Apple and AMD, but its years before you can buy a product with it.

This is an article testing shipping hardware you can buy today.

I feel like that was much more true in the past but the X925 was only spec'd 18 months ago(?) and you can buy it today (I'm using one since October). Intel and AMD also give lots of advance notice on new designs well ahead of anything you can buy. ARM is also moving towards providing completely integrated solutions, so customers like Samsung don't have to take only CPU core and fill in the blanks themselves. They'll probably only get better at shipping complete solutions faster.

Honestly, Apple is the strange one because they never discuss CPUs until they are available to buy in a product; they don't need to bother.

> ARM designs are effectively paper launches.

Won't ARM have validation silicon available to their licensees?

Google outright has worst in class SoCs on both CPU and GPU unfortunately.

If you want something more perf competitive, pick Dimensity, Exynos, or Snapdragon.

This core was released in the MediaTek 9400 in October 2024 some 16 months ago.

The successor of x925 is C1 Ultra and even that was released 6 months ago in September 2025 with the MediaTek 9500 and GeekerWan even has a phone review they did with that chip last year.

For most, it doesn't need to 'meet' Apple's performance. It just needs to be competitive to general hardware of around the -the same price point- category. This is the same problematic statement I hear that a ~$1500 PC laptop just isn't as good as a ~$3000 macbook.

Arm lawyers have the RTL locked down tight. If you find it, it means you are already dead.

You're going to have a much better time finding RiscV cores.

> Sifive is moving fast as far as I know)

worked with their cores in $pastJob. I'd say their main products are flowery promises and long errata sheets.

This is kind of a solution in search for a problem. RISC-V will grow only if people find some value in it. If it solves their actual problems in ways that other architectures can't.

Zoom works fine with Firefox on Android.

Browsers usually have an accessibility option to force the ability to zoom on all websites.