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

161–169 of 169 posts

Re: Arm's Cortex X925: Reaching Desktop Performance

#161

Post by vardump »

Fire-Dragon-DoL wrote: post #158
vardump wrote: post #23

Earlier quoted context omitted.

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?

Depends on the processor's store queue. It might be. Of course if otherMethod() is anything more complicated, 'a' will almost certainly be assigned first. Of course you should still do the order dependent assignment correctly, like by using C++ std::memory_order or atomics.

Re: Arm's Cortex X925: Reaching Desktop Performance

#162

Post by imtringued »

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 doesn't launch their designs to consumers, they launch the designs to SoC vendors. The word paper launch is accurate in the sense that all they publish is the design files.

Re: Arm's Cortex X925: Reaching Desktop Performance

#163

Post by lproven »

rbanffy wrote: post #148
lproven wrote: post #106

Earlier quoted context omitted.

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.

It didn't make it to release, and I believe MS switched internal development more or less as soon as it had an alternative. I do not recall reading any specific detailed look into why, so you may well be right!

Intel let the i860 and indeed the slightly older i960 wither, which was a damned shame. Ditto the Alpha it ended up with, while it sold its Arm licence to Marvell, which at one point recently was worth more than Intel.

I'd like to see a skunkworks project to resurrect one, or several, of these. :-) Attack Arm from a direction it's not expecting. And RISC-V come to that.

Re: Arm's Cortex X925: Reaching Desktop Performance

#164

Post by pjmlp »

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…

Those of us that keep using Windows or macOS, can still find native applications for many cases, especially because the culture of accepting to pay for small utilities.

It is the Year of Desktop Linux that keeps being inundated with Electron crap, to detriment of Gtk, Qt, KDE, and whatever else is out there.

Re: Arm's Cortex X925: Reaching Desktop Performance

#165

Post by aseipp »

brigade wrote: post #156
aseipp wrote: post #99

Earlier quoted context omitted.

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.

Yeah, I was more just trying to paint a broad picture. Nvidia in particular I think had fast and large-ish L1 on Tegra (X2?) despite being tied to 4k pages.

Re: Arm's Cortex X925: Reaching Desktop Performance

#166

Post by dd_xplore »

pjmlp wrote: post #164
dd_xplore wrote: post #9

Earlier quoted context omitted.

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…

Those of us that keep using Windows or macOS, can still find native applications for many cases, especially because the culture of accepting to pay for small utilities. It is the Year of Desktop Linux that keeps being inundated with Electron crap, to detriment of Gtk, Qt, KDE, and whatever else is out there.

Linux apps today dont have that feel of apps that we had in 98/2000 era or even XP era. Windows platform had really good apps.

Re: Arm's Cortex X925: Reaching Desktop Performance

#167

Post by megous »

wmf wrote: post #146
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.

LOL

Re: Arm's Cortex X925: Reaching Desktop Performance

#168

Post by wat10000 »

IshKebab wrote: post #159
wat10000 wrote: post #154

Earlier quoted context omitted.

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.

Memory ordering issues require two sides to manifest, since even the most extreme out-of-order architecture presents itself as in-order to a single thread.

Imagine that code was paired with code in another thread that did:

  *b = newValue;
  barrier();
  *a = 1;
We put a barrier here to ensure the stores don't get reordered, since we must write out the new value in b before writing out the flag in a that tells the other code to use it.

Paired with this, my example above will work fine on an architecture with strong ordering, but will potentially get a bad value into y on archs with weak ordering. The reader may fetch the value in b first, getting the value before the reassignment. It may then fetch the value in a and see 1. This will cause it to use the old value loaded from *b, which is semantically incorrect in this case even though it's perfectly correct according to the architecture and the language spec.

Correct code here would need an acquire barrier on the load of a, paired with a release barrier on the store.

Re: Arm's Cortex X925: Reaching Desktop Performance

#169

Post by martin1975 »

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.

Curious, what type of code and in what language do you write that the compiler wouldn't take care of this without you even trying?
Post reply on HN