Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Arm's Cortex X925: Reaching Desktop Performance

chipsandcheese.com

Post reply on HN
Print view View original

31–40 of 169 posts

Re: Arm's Cortex X925: Reaching Desktop Performance

#31

Post by renewiltord »

ezst wrote: post #10
pdpi wrote: post #2

Kind of weird to see an article about high-performance ARM cores without a single reference to Apple or how this hardware compares to M4 or M5 cores.

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 decade…

Last time I tried, getting Linux working on Apple Silicon actually worked better than on Qualcomm ARM machine (which only support strange Windows).

Re: Arm's Cortex X925: Reaching Desktop Performance

#33

Post by ezst »

tucnak wrote: post #27
ezst wrote: post #10

Earlier quoted context omitted.

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 decade…

FWIW, Apple Virtualization framework is fantastic, and Rosetta 2 is unmatched on other Arm desktops where QEMU is required. For example, you can get Vivado working on Debian guest, macOS host trivially like that.

https://www.macrumors.com/2025/06/10/apple-to-phase-out-rose...

Re: Arm's Cortex X925: Reaching Desktop Performance

#34

Post by amelius »

pdpi wrote: post #14
ezst wrote: post #10

Earlier quoted context omitted.

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 decade…

Sure. Insofar as Apple Silicon beats these things, "I'll take less powerful hardware if it means I'm not stuck with the Apple ecosystem" is a perfectly reasonable tradeoff to make. Two things, though. First, I don't like making blind tradeoffs. If what I need (for whatever reason) is a really beefy ARM CPU, I'd like to know what the "Apple-less tax" costs me (if anything!) Second, the status quo is that Apple Silicon…

Let's say my company makes systems for in-flight entertainment, with content from my company.

I am looking for a CPU.

I don't want to confront my users with "Please enter your Apple ID" or any other unexpected messages that I have no control over.

Is Apple M series an option for me?

Re: Arm's Cortex X925: Reaching Desktop Performance

#35

Post by Orygin »

ezst wrote: post #33
tucnak wrote: post #27

Earlier quoted context omitted.

FWIW, Apple Virtualization framework is fantastic, and Rosetta 2 is unmatched on other Arm desktops where QEMU is required. For example, you can get Vivado working on Debian guest, macOS host trivially like that.

https://www.macrumors.com/2025/06/10/apple-to-phase-out-rose...

They are not phasing it out for virtualization.

Re: Arm's Cortex X925: Reaching Desktop Performance

#36

Post by llm_nerd »

pdpi wrote: post #2

Kind of weird to see an article about high-performance ARM cores without a single reference to Apple or how this hardware compares to M4 or M5 cores.

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.

Re: Arm's Cortex X925: Reaching Desktop Performance

#37

Post by Someone »

octachron wrote: post #24
runeks wrote: post #11

Earlier quoted context omitted.

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

The issue is that the C memory model allows more behaviours than the memory model of x86-64 processors. You can thus write code which is incorrect according to the C language specification but will happen to work on x86-64 processors. Moving to arm64 (with its weaker memory model than x86-64) will then reveal the latent bug in your program.

And “happen to work on x86-64 processors” also will depend on the compiler. If you write

  *a = 1;
  *b = 'p';
both the compiler and the CPU can freely pick the order in which those two happen (or even execute them in parallel, or do half of one first, then the other, then the other half of the first, but I think those are hypothetical cases)

x86-64 will never do such a swap, but x86-64 compilers might.

If you write

  *a = 1;
  *b = 2;
, things might be different for the C compiler because a and b can alias. The hardware still is free to change that order, though.

Re: Arm's Cortex X925: Reaching Desktop Performance

#38

Post by ezst »

spiderfarmer wrote: post #18
ezst wrote: post #10

Earlier quoted context omitted.

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 decade…

> represents a commitment to the Apple software ecosystem I don't see how that's holding you back from using these tools for your work anymore than using a Makita power tool with LXT battery pack.

Pretty simply because I don't want to use MacOS, its terrible window management, quirks and idiosyncrasies. In your comparison, my gripe wouldn't be about the hassle of finding 3rd-party compatible batteries, but about the daily handling of the Makita while knowing the DeWalt to be more ergonomic and better suited to my needs.

Re: Arm's Cortex X925: Reaching Desktop Performance

#39

Post by mrweasel »

runeks wrote: post #11
dinglo wrote: post #6

If ARM starts dominating in desktop and laptop spaces with a quite different set of applications, might we start seeing more software bugs around race conditions? Caused by developers writing software with X86 in mind, with its differing constraints on memory ordering.

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

OpenBSD famously keeps a lot of esoteric platforms around, because running the same code on multiple architectures reveal a lot of bugs. At least that was one of the arguments previously.

Re: Arm's Cortex X925: Reaching Desktop Performance

#40

Post by dgacmu »

hrmtst93837 wrote: post #32
pdpi wrote: post #2

Kind of weird to see an article about high-performance ARM cores without a single reference to Apple or how this hardware compares to M4 or M5 cores.

[flagged]

Most of your comment history reads like LLM generated trite comments. Are you human?
Post reply on HN