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

141–150 of 169 posts

Re: Arm's Cortex X925: Reaching Desktop Performance

#141

Post by IshKebab »

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.

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.

Re: Arm's Cortex X925: Reaching Desktop Performance

#142

Post by rbanffy »

barrkel wrote: post #76
Incipient wrote: post #7

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)

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…

There is a whole universe of good-enough desktop computers that doesn't care that much about performance, but where power consumption is important, because it makes the computer bulky, noisy, and expensive.

I'd love to have a Xeon 6, a big EPYC, or an AmpereOne (or a loaded IBM LinuxOne Express) as my daily driver, but that's just not something I can justify. It'd not be easy to come up with something for all this compute capacity to do. A reasonable GPU is a much better match for most of my workloads, which aren't even about pushing pixels anymore - iGPUs are enough these days - but multiplying matrices with embarrassingly low precision, so it can pretend to understand programming tasks.

Re: Arm's Cortex X925: Reaching Desktop Performance

#143

Post by rbanffy »

IshKebab wrote: post #141
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.

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…

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

At least in my house, ARM cores outnumber x86 cores by at least four to one. And I'm not even counting the 32-bit ARM cores in embedded devices.

There is a lot of space for memory ordering bugs to manifest in all those devices.

Re: Arm's Cortex X925: Reaching Desktop Performance

#144

Post by dmitrygr »

joha4270 wrote: post #138
dmitrygr wrote: post #116

Earlier quoted context omitted.

that will break if any page is mapped at two VAs, you'll end up with conflicting cache lines for the same page...

The L2 already keeps track of what lines are somewhere in L1's for managing coherency. Divide the cache into "meta-caches" indexed by the virtual bits and treat them as separate from the L2's point of view. Duplicate the data and if somebody writes back invalidate all the other copies. The hardware already exists for doing this on any multicore system. Sure, you will end up duplicating data sometimes and it will actu…

this "divide" thing will add latency which you really do not want to add to L1 hits

Re: Arm's Cortex X925: Reaching Desktop Performance

#145

Post by rbanffy »

dd_xplore wrote: post #9
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.

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(exce…

> Nowadays most PCs feel like a random terminal

It's a fun perception. For the longest time, all the "serious" computers were used through networks and terminals and didn't even come with any ability to connect a monitor or a keyboard (although a serial terminal would work as the system console). I used to joke (usually looking at Unisys Windows-based big servers), if the computer had VGA and PS/2 ports, it wasn't a computer, but a toy. Those Unisys servers weren't toys, but you could run Pinball and Minesweeper directly on them, which kind of said otherwise.

I think we got used to such levels of platform bloat that we don't care if the UI toolkit these days is bigger than the entire operating system that runs 95% of the world's payment transactions.

Re: Arm's Cortex X925: Reaching Desktop Performance

#146

Post by wmf »

megous wrote: post #124

BTW, does anyone have some pointers to where one can find an oldish in-order Cortex-A core (like A53) in verilog RTL form? I know ARM must give this out to companies that implement ARM based SoCs for eg. purpose of validation on FPGA. So far I've only found various M cores online. It would be fun to have something to experiment with on a cheapish FPGA like Kintex XC7-K480T, that may have enough resources for some in-…

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

Re: Arm's Cortex X925: Reaching Desktop Performance

#147

Post by rbanffy »

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.

This architecture trick was often used for precisely this - finding bugs in the program that would work in one architecture and fail in another. A very common class of issues like these was about endianness, and PowerPC was very handy because it could boot as both high and low-endian modes (I think I remember different versions of Linux for each mode, but I'm no longer sure).

Re: Arm's Cortex X925: Reaching Desktop Performance

#148

Post by rbanffy »

lproven wrote: post #106
mrweasel wrote: post #39

Earlier quoted context omitted.

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.

Which is why Windows NT was multiplatform in 1993. Developed on Intel i860, then MIPS, and only then on x86, alongside Alpha.

I don't think the i860 port lasted very long. IIRC, the performance in context switches was atrocious.

Re: Arm's Cortex X925: Reaching Desktop Performance

#149

Post by my123 »

rayiner wrote: post #80

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. Google Pixels that came out in the fall are still on the X4, which was introduced in 2023. At this rate, Pixel 11 will launch with X925, which is an Apple A17/M3 tier core, when Apple is on the A20: https://wccftech.com/apple-a20-and-a20-pro-all-technol…

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.

Re: Arm's Cortex X925: Reaching Desktop Performance

#150

Post by rbanffy »

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…

> Apple Silicon is the undisputed king of ARM CPU performance

The cores, yes, but you can get an AmpereOne with 192 ARM cores (or rent out beefier machines from AWS and Azure). If you need to run macOS, then you are tied to Apple, but if all you want is ARM (for, say, emulated embedded hardware development), you have other options in the ARM ecosystem. I'm actually surprised Ampere maxes out at 192 cores when Intel Xeon 6+ has parts with 288 cores on a single socket (and that can go up to 4 sockets).

I wonder how many cores you'd need to make htop crash.

Post reply on HN