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

131–140 of 169 posts

Re: Arm's Cortex X925: Reaching Desktop Performance

#131

Post by hajile »

adrian_b wrote: post #25
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)

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…

SIMD workloads on CPU tend to be bursty. If your workload is all SIMD with few other instructions or branches, it's almost certainly going to be faster on a GPU or SME co-processor.

If there's space between the SIMD instructions, then double-pumping or even quad-pumping isn't very expensive (and with 6 SIMD ports, it might even be basically free).

Re: Arm's Cortex X925: Reaching Desktop Performance

#132

Post by peterfirefly »

bluGill wrote: post #45
pdpi wrote: post #14

Earlier quoted context omitted.

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…

Why do you need ARM? There is nothing magic, most CPUs are an internal instruction set with a decoder on top. bad as x86 is, decoding is not the issue. they can make lower power use x86 if they want. They can also make mips or riskv chips that are good.

Memory models matter.

Re: Arm's Cortex X925: Reaching Desktop Performance

#133

Post by pdpi »

jakogut wrote: post #120
guerrilla wrote: post #114

Earlier quoted context omitted.

Are M* chips even beating AMD anyway?

On average according to Geekbench, the M5 compared to the 9950X is ~17% faster in single thread performance and ~30% slower in multithread performance. Individual benchmarks tell the bigger picture. These two are optimized for different use cases, with Apple heavily leaning towards low latency single thread throughput with low sustained power usage. https://browser.geekbench.com/v6/cpu/compare/16833358?baseli... EDIT…

That M4 Max is in a laptop. The Mac Studio version is a couple percent faster still:

https://browser.geekbench.com/v6/cpu/compare/16839304?baseli...

The M3 Ultra sacrifices a bunch of single-thread performance for not that much of a multithreaded gain:

https://browser.geekbench.com/v6/cpu/compare/16839654?baseli...

Re: Arm's Cortex X925: Reaching Desktop Performance

#134

Post by tliltocatl »

rslashuser wrote: post #98
adgjlsfhk1 wrote: post #94

Earlier quoted context omitted.

This the the most cursed part of modern cpu design, but the TLDR is that programs use virtual addresses while CPUs use physical addresses which means that CPU caches need to include the translation from virtual to physical adress. The problem is that for L1 cache, the latency requirement of 3-4 cycles is too strict to first do a TLB lookup and then an L1 cache lookup, so the L1 can only be keyed on the bits of ram wh…

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 painful for the upper layers in exchange for a few 0.1%s of speed. You could also probably gain some speed by dropping byte access and saying the minimal addressable unit is now 32 bits. Please don't. If you need larger L1 cache - just increase associativity.

Re: Arm's Cortex X925: Reaching Desktop Performance

#135

Post by spijdar »

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…

Funny, most of what you described sums up the Alpha architecture. 8KB pages + huge pages and, initially, only word-addressable memory, no byte access.

(Of course, it only took a few years for this to be rectified with the byte-word extension, which became required by ~all "real software" that supported Alpha)

It's also one of the only architectures Windows NT supported that didn't have 4KB pages, along with Itanium. I've wondered how (or if?) it handled programs that expect 4KB pages, especially in the x86 translation subsystem.

Re: Arm's Cortex X925: Reaching Desktop Performance

#136

Post by sylware »

dmitrygr wrote: post #119
sylware wrote: 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…

> Sifive is moving fast as far as I know) worked with their cores in $pastJob. I'd say their main products are flowery promises and long errata sheets.

Which models? Which nasty issues did you encounter?

Re: Arm's Cortex X925: Reaching Desktop Performance

#137

Post by sylware »

GoblinSlayer wrote: post #97
sylware wrote: post #69

Earlier quoted context omitted.

Yep, licensing fee and IP usage restrictions is a massive decision point on some silicon markets. The other massive point: RISC-V integrates a lot of CPU "we know now" in a very elegant "sweet spot". And it is not china only, the best implementations are US, and RISC-V is a US/berkley initiative re-centered in switzerland for "neutrality" reasons. If good large RISC-V implementations do reach TMSC silicon process (5G…

Standard ISA being rv64gc? Isn't MIPS 2 easier to emulate? It has less funky encoding.

There are tons of RISC-V SOCs and mini-boards. Ez and inexpensive native port...

Re: Arm's Cortex X925: Reaching Desktop Performance

#138

Post by joha4270 »

dmitrygr wrote: post #116
joha4270 wrote: post #108

Earlier quoted context omitted.

Can you not take some of those virtual bits and get more buckets that way? I am sure it will make things more complicated if nothing else by them possibly being mapped to the same physical page, but it doesn't sound like an impossible barrier. Maybe something terrible where a cache line keeps bouncing between different buckets in the rare case that does happen, but as long as you can keep the common case as fast... O…

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 actually be slower if you're actually writing to aliased locations. But is this happening often enough to be a problem compared to generally having a bigger cache?

It sounds to me like an engineering tradeoff that might or might not make sense, not a hard limit which at least was what I think was being asserted. But as I also said, L1 sizes hasn't increased in a while and smart people are working on it, so there is probably something I don't know.

Re: Arm's Cortex X925: Reaching Desktop Performance

#139

Post by ddtaylor »

GaggiX wrote: post #5
ddtaylor wrote: post #4

Can't zoom any of the content on mobile so most of the charts are unreadable.

Browsers usually have an accessibility option to force the ability to zoom on all websites.

This website has those features disabled in Chrome or Brave. Apparently the Zoom option will only appear for "sites that support this feature". This is because they set this header in the meta tags:

    user-scalable=0

Re: Arm's Cortex X925: Reaching Desktop Performance

#140

Post by spijdar »

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.

Big endian MIPS, no less! At least initially.
Post reply on HN