3 ms·

But stack accesses are generally perfectly predicted, meaning that your loads from stack get executed and the data loaded into those extra registers long before

• tux3 11y ago
  The prefetcher does a great job, but it's not remotely enough to make stack access penalties disappear. It's trivial to write microbenchmarks where spilling hot read/write variables to the stack destroys performance, much harder to find special cases where the difference isn't noticeable.
  • stephencanon 11y ago
    The hot region of the stack is, for practical purposes, always resident in D$, so there's no prefetching to be done. I think that you're really talking about out-of-order and speculative loads. You're absolutely correct that spill/fill can be catastrophic for performance, however.
• stephencanon 11y ago
  There are two common scenarios where spill/fill has catastrophic performance implications: - Workloads that are LSU-bound, like simple per-pixel image operations and level 1 and level 2 BLAS[1]. Here every spill is taking up two LSU dispatch slots that would otherwise be used for "real work". - Spilled loop-carried dependencies in tight loops; here you're simply adding latency to the critical path. Both are fairly rare in "generic" code, but very real concerns for compute kernels. [1] The BLAS operations have few enough buffers that spill/fill never actually happens in practice, but more complex operations on multiple buffers do run into this.