Hacker News Reader

Comment by eqvinox | Hacker News Reader

Reading the section under "Load Another FP Pipe?" I'm coming away with the impression that it's not the LSU but rather total overall load that causes trouble. While that section is focused on transition time, the end steady state is also slower…

View on HN

I haven’t read the article yet, but back when I tried to get to over 100 GB/s IO rate from a bunch of SSDs on Zen4 (just fio direct IO workload without doing anything with the data), I ended up disabling Core Boost states (or maybe something else in BIOS too), to give more thermal allowance for the IO hub on the chip. As RAM load/store traffic goes through the IO hub too, maybe that’s it?

I don't think these things are related, this is talking about the LSU right inside the core. I'd also expect oscillations if there were a thermal problem like you're describing, i.e. core clocks up when IO hub delivers data, IO hub stalls, causes core to stall as well, IO hub can run again delivering data, repeat from beginning.

(Then again, boost clocks are an intentional oscillation anyway…)

Ok, I just read through the article. As I understand, their tests were designed to run entirely on data on the local cores' cache? I only see L1d mentioned there.

Yes, that's my understanding of "Zen 5 also doubles L1D load bandwidth, and I’m exercising that by having each FMA instruction source an input from the data cache." Also, considering the author's other work, I'm pretty sure they can isolate load-store performance from cache performance from memory interface performance.

Reply on news.ycombinator.com