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

151–160 of 169 posts

Re: Arm's Cortex X925: Reaching Desktop Performance

#151

Post by rbanffy »

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…

> ARM designs are effectively paper launches.

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

Re: Arm's Cortex X925: Reaching Desktop Performance

#152

Post by adgjlsfhk1 »

tliltocatl wrote: post #134
rslashuser wrote: post #98

Earlier quoted context omitted.

Nice HN explanation! One hopes we will not be living with 4kb pages forever, and perhaps L1 performance will be one more reason.

I'd really hope we do live with 4kb pages forever. Variable page size would make many remapping optimizations (i. e. continuous ring buffers) much harder to do, so we would need more abstraction layers, and more abstraction layers will eat away all the performance gains while also making everything more fragile and harder to understand. Hardware people really love those "performance hacks" that make live a more painf…

The extra L1 cache from a 64k page is on it's own a ~5-10% perf improvement (and it decreases power use by reducing the number of times you go out to L2.

Re: Arm's Cortex X925: Reaching Desktop Performance

#153

Post by jasomill »

rbanffy wrote: post #147
octachron wrote: post #24

Earlier quoted context omitted.

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).

Starting with POWER8, the Linux kernel and some of the BSDs support 64-bit PowerPC in both big- and little-endian modes. Older PowerPC chips had more limited support for little-endian, and all the commercial desktop/server PowerPC OSes that come immediately to mind (classic Mac OS, Mac OS X, NEXTSTEP / OpenStep, OS/400 / IBM i, AIX, BeOS) are big-endian only.

As you'd expect, Linux distribution support for big- and little-endian varies.

Re: Arm's Cortex X925: Reaching Desktop Performance

#154

Post by wat10000 »

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…

It's definitely a real issue in real code, since the CPU isn't bound by things like function boundaries or alias analysis or pointer validity. For example:

  x = *a;
  if (x) y = *b;
The compiler cannot reorder the load of b before the load of a, because it may not be a valid pointer if x is false. But the CPU is free to speculate long ahead, and if the pointer in b isn't valid, that's fine, the CPU can attempt a speculative load and fail.

It's not particularly common and code that has this issue will probably crash only rarely, but it's not too hard to do.

Re: Arm's Cortex X925: Reaching Desktop Performance

#155

Post by wat10000 »

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?

What is "correct"? If you write code that stores two values and the compiler emits two stores, that's correct. If the programmer has judged that the order of those stores is important, the compiler may not have any obligation to agree with the programmer. And even if it does, the compiler is likely only obligated to ensure the ordering as seen by the current thread, so two plain load instructions in the proper order would be enough to be "correct." But if the programmer is relying on those stores being seen in a particular order by other threads, then there's a problem.

Compilers can only be relied on to emit code that's correct in terms of the language spec, not the programmer's intent.

Re: Arm's Cortex X925: Reaching Desktop Performance

#156

Post by brigade »

aseipp wrote: post #99
joha4270 wrote: post #89

Earlier quoted context omitted.

I'm sorry, I'm clearly missing something but why would page size impact L1 cache size?

When you do a cache lookup, there is a "tag" which you use as an index during lookup. But once you do the lookup, you may need to walk a few entries in the corresponding "bucket" (identified by that tag) to find the matching cache line. The number of entries you walk is the associativity of the cache e.g. 8-way or 12-way associativity means there are 8 or 12 entries in that bucket. The larger the associativity, the l…

It’s not a hard limit, especially if you aren’t pushing the frequency wall like Intel. AMD used to use a 2-way 64kb L1, Intel has an 8-way 64kb L1i on Gracemont, and more to the point, high-end ARM Cortex has had 4-way 64kb L1 caches since before they even supported 16kb pages.

Re: Arm's Cortex X925: Reaching Desktop Performance

#157

Post by BlobberSnobber »

lproven wrote: post #105
BlobberSnobber wrote: post #58

Earlier quoted context omitted.

As someone who uses Linux, macOS and Windows interchangeably, I'm curious to know what you're using. I learned to live with macOS, but I also like and use Gnome, which many Linux-only people hate. I tried most WMs on Linux, like Hyprland, Sway, i3, but none ever felt worth the config hassle when compared to the sane defaults of Gnome.

> the sane defaults of Gnome. I have to admit that when I read this, my eyebrows went up so far that my hat moved.

I know what you mean, but Gnome was the DE that clicked the most for me (after I gave it a real try). I liked Gnome 2 and then 3 made me switch to KDE, then switched back. So I was actually completely wrong and, while writing this comment, I remembered what a pain it was to learn Gnome back then lol

Re: Arm's Cortex X925: Reaching Desktop Performance

#158

Post by Fire-Dragon-DoL »

vardump wrote: post #23
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.

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

Is this only for constants or even for instructions?

Like:

a=fooMethod(); b=otherMethod()

Will this be reordered?

Re: Arm's Cortex X925: Reaching Desktop Performance

#159

Post by IshKebab »

wat10000 wrote: post #154
IshKebab wrote: post #141

Earlier quoted context omitted.

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…

It's definitely a real issue in real code, since the CPU isn't bound by things like function boundaries or alias analysis or pointer validity. For example: x = *a; if (x) y = *b; The compiler cannot reorder the load of b before the load of a, because it may not be a valid pointer if x is false. But the CPU is free to speculate long ahead, and if the pointer in b isn't valid, that's fine, the CPU can attempt a specula…

I don't understand your example. That code is correct on both architectures.

Re: Arm's Cortex X925: Reaching Desktop Performance

#160

Post by IshKebab »

rbanffy wrote: post #143
IshKebab wrote: post #141

Earlier quoted context omitted.

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.

The number of cores is fairly similar actually. X86 has been commonly 2 or 4 core for decades, and ARM is only recently more than that.
Post reply on HN