Live data from Hacker News

Always Bump Downwards (2019)

fitzgeraldnick.com

71–74 of 74 posts

Re: Always Bump Downwards (2019)

#71
post #68

Earlier quoted context omitted.

Your stack is entirely data, why do you think a CPU couldn't predict access patterns on stack? Prefetchers can predict negative offset/decrements since 1980s

Because stacks aren’t unbounded. You grow and shrink them. Therefore, regardless of which direction it grows in, it also shrinks in the opposite direction with the same likelihood.

And?

> fact that downward bump is just not what the HW expects you to do.

What fact is this? and what does it have to do with stack being bounded? (bounds of stack are unknown to most micro architectural state and only stored in OS structures).

HW prefetchers support access pattern in either direction, so do load/store instructions (stm(fd)/ldm(fd); ltp/stp;)

Re: Always Bump Downwards (2019)

#72
post #71

Earlier quoted context omitted.

Because stacks aren’t unbounded. You grow and shrink them. Therefore, regardless of which direction it grows in, it also shrinks in the opposite direction with the same likelihood.

And? > fact that downward bump is just not what the HW expects you to do. What fact is this? and what does it have to do with stack being bounded? (bounds of stack are unknown to most micro architectural state and only stored in OS structures). HW prefetchers support access pattern in either direction, so do load/store instructions (stm(fd)/ldm(fd); ltp/stp;)

The fact that stacks are bounded means you both push and you pop. Just as frequently as a function calls another one resulting in memory ops moving to lower addresses, functions also return causing memory ops to move back to higher addresses. Pushes and pops are balanced. Why do we know they are balanced? Because the stack is bounded.

So - the direction of stack growth isn’t interesting to prefetching strategy.

Re: Always Bump Downwards (2019)

#73
post #71

Earlier quoted context omitted.

And? > fact that downward bump is just not what the HW expects you to do. What fact is this? and what does it have to do with stack being bounded? (bounds of stack are unknown to most micro architectural state and only stored in OS structures). HW prefetchers support access pattern in either direction, so do load/store instructions (stm(fd)/ldm(fd); ltp/stp;)

The fact that stacks are bounded means you both push and you pop. Just as frequently as a function calls another one resulting in memory ops moving to lower addresses, functions also return causing memory ops to move back to higher addresses. Pushes and pops are balanced. Why do we know they are balanced? Because the stack is bounded. So - the direction of stack growth isn’t interesting to prefetching strategy.

Sure, but push/pop are not the only ways to access stack.

Moreover, I'm still wondering what you mean by this:

> Yeah I’m also amused that they didn’t get into the fact that downward bump is just not what the HW expects you to do.

What is this fact? Why does HW not expect you to bump addresses downwards?

Re: Always Bump Downwards (2019)

#74

I've heard that the Hotspot JVM uses a bump allocator but don't know the details. I'm sure it's heavily optimized though, so I'm curious about how this compares.

Here's an article[0] with some information on Hotspot's bump allocators.

[0] https://shipilev.net/jvm/anatomy-quarks/4-tlab-allocation/

Post reply on HN