Live data from Hacker News

Arm's Cortex X925: Reaching Desktop Performance

chipsandcheese.com

21–30 of 169 posts

Re: Arm's Cortex X925: Reaching Desktop Performance

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

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

Re: Arm's Cortex X925: Reaching Desktop Performance

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

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.

Re: Arm's Cortex X925: Reaching Desktop Performance

#24
post #11
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?

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.

Re: Arm's Cortex X925: Reaching Desktop Performance

#25

Without being a cpu geek, a lot of the branch prediction details go over my head, however generally a good review. I liked the detail of performance on more complex workloads where IPC can get muddy when you need more instructions. I feel these days however, for any comparison of performance, power envelope needs to be included (I realise this is dependent on the final chip)

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.

Re: Arm's Cortex X925: Reaching Desktop Performance

#26
But with hardware IP locks like x86_64.

Better favor as much as possible RISC-V implementations.

But, I don't know if there are already good modern-desktop-grade RISC-V implementations (in the US, Sifive is moving fast as far as I know)... and the hard part: accessing the latest and greatest silicon process of TMSC, aka ~5GHz.

Those markets are completely saturated, namely at best, it will be very slow unless something big does happen: for instance AMD adapts its best micro-architecture to RISC-V (ISA decoding mostly), etc.

And if valve start to distribute a client with a strong RISC-V game compilation framework...

Re: Arm's Cortex X925: Reaching Desktop Performance

#27
post #10
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…

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.

Re: Arm's Cortex X925: Reaching Desktop Performance

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

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

And Qualcomm.

Re: Arm's Cortex X925: Reaching Desktop Performance

#29

Without being a cpu geek, a lot of the branch prediction details go over my head, however generally a good review. I liked the detail of performance on more complex workloads where IPC can get muddy when you need more instructions. I feel these days however, for any comparison of performance, power envelope needs to be included (I realise this is dependent on the final chip)

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

Still, what percentage of software uses AVX512 for its core functionality, so vector performance matters in practice?

Re: Arm's Cortex X925: Reaching Desktop Performance

#30
post #26

But with hardware IP locks like x86_64. Better favor as much as possible RISC-V implementations. But, I don't know if there are already good modern-desktop-grade RISC-V implementations (in the US, Sifive is moving fast as far as I know)... and the hard part: accessing the latest and greatest silicon process of TMSC, aka ~5GHz. Those markets are completely saturated, namely at best, it will be very slow unless somethi…

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.
Post reply on HN