Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Test Results for AMD Zen 5

agner.org

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Test Results for AMD Zen 5

#71

Post by Sesse__ »

menaerus wrote: post #70
Sesse__ wrote: post #68

Earlier quoted context omitted.

Me neither, especially since it was rather branchy (though almost all of the branches were, obviously, easily predictable). It was dominated by simple AND/OR/TEST, though, which I guess can go into a bazillion ports. Perhaps instruction fusion somehow played into it?

Probably everything that there is including the instruction fusion, no decoding aka uop cache, ideal port dispatching, no data dependency etc. If it was a loop then perhaps even LSD.

It was a 20-way nested loop (!), but it probably spent all (>99%) of its time in a few of the depths. Pretty sure all of the actually executed code would fit into the LSD.

Then I moved stuff into huge precalced arrays instead, and it became intensely memory bound. :-)

Re: Test Results for AMD Zen 5

#72

Post by p_l »

arrakark wrote: post #14
ashvardanian wrote: post #5

> All vector units have full 512 bits capabilities except for memory writes. A 512-bit vector write instruction is executed as two 256-bit writes. That sounds like a weird design choice. Curious if this will affect memcpy-heavy workloads. Writes aside, Zen5 is taking much longer to roll out than I thought, and some of AMD's positioning is (almost expectedly) misleading, especially around AI. AMD's website claims Zen5…

Cache-line bursts/beats tend to be standardized to 64B in lots of NoC architectures.

64 byte cache line size matches 64byte single burst transaction on DDR3-5, and ganged dual channel transaction on DDR2. Matching those together means you have a nice 1-to-1 relationship between filling a cache line and single fast memory transaction

Re: Test Results for AMD Zen 5

#73

Post by p_l »

rpiguy wrote: post #8
ashvardanian wrote: post #5

> All vector units have full 512 bits capabilities except for memory writes. A 512-bit vector write instruction is executed as two 256-bit writes. That sounds like a weird design choice. Curious if this will affect memcpy-heavy workloads. Writes aside, Zen5 is taking much longer to roll out than I thought, and some of AMD's positioning is (almost expectedly) misleading, especially around AI. AMD's website claims Zen5…

It may be easier for the memory controller to schedule two narrower writes than waiting for one 512-bit block or perhaps they just didn't substantially update the memory controller and so it still has to operate as it did in Zen 4.

Zen 4 memory controllers operate preferably in multiplies of 512bits (single burst on 16n prefetch mode DDR5 channel, 4 channels on consumer Zen4 devices)

Re: Test Results for AMD Zen 5

#74

Post by menaerus »

Sesse__ wrote: post #71
menaerus wrote: post #70

Earlier quoted context omitted.

Probably everything that there is including the instruction fusion, no decoding aka uop cache, ideal port dispatching, no data dependency etc. If it was a loop then perhaps even LSD.

It was a 20-way nested loop (!), but it probably spent all (>99%) of its time in a few of the depths. Pretty sure all of the actually executed code would fit into the LSD. Then I moved stuff into huge precalced arrays instead, and it became intensely memory bound. :-)

Yeah, it might be the LSD then, basically no frontend involved after the first loop iteration, and then no bottleneck in the backend as well.

So, what did you end up having in the code? Ugly and fast or nice and slow? :)

Re: Test Results for AMD Zen 5

#75

Post by Sesse__ »

menaerus wrote: post #74
Sesse__ wrote: post #71

Earlier quoted context omitted.

It was a 20-way nested loop (!), but it probably spent all (>99%) of its time in a few of the depths. Pretty sure all of the actually executed code would fit into the LSD. Then I moved stuff into huge precalced arrays instead, and it became intensely memory bound. :-)

Yeah, it might be the LSD then, basically no frontend involved after the first loop iteration, and then no bottleneck in the backend as well. So, what did you end up having in the code? Ugly and fast or nice and slow? :)

It's essentially research code, so it's getting uglier and uglier and faster and faster :-) It has stuff like “if I remove this assert(), then Clang does something stupid and 30% of CPU time is spent stalling on this single instruction, so meh, leave it in”. It's not going to be maintained once it's done its computation job. (https://oeis.org/draft/A286874 if you're curious.)

Re: Test Results for AMD Zen 5

#76

Post by menaerus »

Sesse__ wrote: post #75
menaerus wrote: post #74

Earlier quoted context omitted.

Yeah, it might be the LSD then, basically no frontend involved after the first loop iteration, and then no bottleneck in the backend as well. So, what did you end up having in the code? Ugly and fast or nice and slow? :)

It's essentially research code, so it's getting uglier and uglier and faster and faster :-) It has stuff like “if I remove this assert(), then Clang does something stupid and 30% of CPU time is spent stalling on this single instruction, so meh, leave it in”. It's not going to be maintained once it's done its computation job. ( https://oeis.org/draft/A286874 if you're curious.)

> if I remove this assert(), then Clang does something stupid and 30% of CPU time is spent stalling on this single instruction, so meh, leave it in

Classic compiler games and similar happened to me just recently when I wrote a micro-optimized SIMD code for some monotonically increasing integer sequence utility that achieved like 80% of the theoretical IPC (for skylake-x) in ubenchmarks, however, once I moved the code from ubenchmark to the production code what I saw was surprising (or not really) - compiler merged my carefully optimized SIMD code with the surrounding code and largely nullified the optimizations I've done.

Re: Test Results for AMD Zen 5

#77

Post by Sesse__ »

menaerus wrote: post #76
Sesse__ wrote: post #75

Earlier quoted context omitted.

It's essentially research code, so it's getting uglier and uglier and faster and faster :-) It has stuff like “if I remove this assert(), then Clang does something stupid and 30% of CPU time is spent stalling on this single instruction, so meh, leave it in”. It's not going to be maintained once it's done its computation job. ( https://oeis.org/draft/A286874 if you're curious.)

> if I remove this assert(), then Clang does something stupid and 30% of CPU time is spent stalling on this single instruction, so meh, leave it in Classic compiler games and similar happened to me just recently when I wrote a micro-optimized SIMD code for some monotonically increasing integer sequence utility that achieved like 80% of the theoretical IPC (for skylake-x) in ubenchmarks, however, once I moved the code…

Haha, yes, autovectorization is so much in the way sometimes. I have a bunch of hard-coded AVX2/AVX512 intrinsics lying around since the compiler can do it fine on Compiler Explorer but not in context. Still, having a stall on a single 512-bit add like that suggests something very odd in the µarch. Perhaps something like “we're all out of physical registers and we're going into some kind of panic mode” that is avoided by inserting the assert() branches and slowing things down. No idea, I'm not a Zen microarchitecture expert.

Edit: I ran the code on an Intel CPU (Kaby Lake, on my laptop) and there's no slowdown when removing the assert(). So it really seems to be something Zen-specific and weird.

Re: Test Results for AMD Zen 5

#78

Post by menaerus »

Sesse__ wrote: post #77
menaerus wrote: post #76

Earlier quoted context omitted.

> if I remove this assert(), then Clang does something stupid and 30% of CPU time is spent stalling on this single instruction, so meh, leave it in Classic compiler games and similar happened to me just recently when I wrote a micro-optimized SIMD code for some monotonically increasing integer sequence utility that achieved like 80% of the theoretical IPC (for skylake-x) in ubenchmarks, however, once I moved the code…

Haha, yes, autovectorization is so much in the way sometimes. I have a bunch of hard-coded AVX2/AVX512 intrinsics lying around since the compiler can do it fine on Compiler Explorer but not in context. Still, having a stall on a single 512-bit add like that suggests something very odd in the µarch. Perhaps something like “we're all out of physical registers and we're going into some kind of panic mode” that is avoide…

I started to appreciate that compilers can do only as much and from my experience auto-vectorization doesn't really shine that much, it leaves a lot of performance on the table, and then it also messes up with the hand optimized code.

> So it really seems to be something Zen-specific and weird.

Number and/or type of ports. Perhaps even the code generation is different so it could be the compiler backend differences too for different uarchs

Re: Test Results for AMD Zen 5

#79

Post by sliken »

varispeed wrote: post #56
makeitdouble wrote: post #38

Earlier quoted context omitted.

Nowadays laptops are majorly used as desktop hybrids. Getting near desktop performance when plugged but portability and lower consumption when unplugged is a pretty good tradeoff.

Friend of mine has laptop with Intel Ultra 9 185h. It is always plugged because when you don't plugin in, it is crawling (like even struggles to open Word). Fans are always spinning and it is loud. For doing any kind of work that requires focus it is an absolute nightmare. But she need a laptop to occasionally take it to Uni.

Sounds like my macbook 16" with the Intel i9. Just about anything, full screen video call, backups, patching, etc it sounds like a hair dryer. I'm not surprised there's various docks, stands, etc that include supplemental cooling.

I'm jealous of the m series macbooks, fast, quiet, and cool on wall or battery.

Re: Test Results for AMD Zen 5

#80

Post by chemmail »

makeitdouble wrote: post #60
varispeed wrote: post #56

Earlier quoted context omitted.

Friend of mine has laptop with Intel Ultra 9 185h. It is always plugged because when you don't plugin in, it is crawling (like even struggles to open Word). Fans are always spinning and it is loud. For doing any kind of work that requires focus it is an absolute nightmare. But she need a laptop to occasionally take it to Uni.

> Intel Ultra 9 185h The CPU in itself should be pretty good by modern standards: https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+Ultra+9+... > (like even struggles to open Word). Her issue is not the form factor. Is it the RAM ? did she activate all the marketing apps ? Is a bitcoin farmer running in the background ? I don't know, but it's worth looking into it. For comparison, I have at hand a Surface Pro 8 tha…

Could be the low power ecores being in use somehow? Meteor Lake has 3 types of core with 2 lpE cores in the SOC to try to turn off the Main P and E core tile. Lunar Lake removed the lpE cores and it does feel faster when surfing pages like reddit than my 12th gen and 5000hz laptops. I also tried the Ryzen AI and it is pretty close but 20% less battery life. They get a pretty crazy 15hr battery life now.
Post reply on HN