3 ms·

One thing I'd love to see is to have enough L1 data cache per core for a modest amount of stack space. Not so critical on GPU's but would make a huge differenc

by socmag 9y ago

One thing I'd love to see is to have enough L1 data cache per core for a modest amount of stack space. Not so critical on GPU's but would make a huge difference for CPU's and languages that can take benefit. Give me a meg or two to play with. Would make a huge difference for data heavy workloads. You could even go as far as having a separate cache just for stack. I mean, by its very definition it is isolated. It's the "register file" of CISC machines

nhaehnle 9y ago
I don't think that idea makes sense. A lot of stack space is unused at any particular time. There's not a one-size-fits-all partition that makes sense, and it's not something that programs could easily tune either. Some obvious stack-related ideas that are worth exploring IMHO are (1) using the stack pointer to guide the prefetcher, to run ahead of cache misses when you return from subroutines and go up the stack; and (2) having an instruction that helps avoid unneeded cache misses when going down the stack; for example, a dedicated instruction for decrementing the stack pointer which zeros entire cache lines directly in L1 without loading them. Or perhaps, for more generality, an instruction for marking any arbitrary address range in this way. Who knows, at least the first one might already be in use in some microarchitectures!
- socmag 9y ago
  Yes I agree that a lot of stack space goes unused right now, that is for sure, but the nice thing about the stack it is definitely thread/core local, and if you did have fast-stack capability we would definitely use it. What I was thinking about was a separate bus to a per thread stack space with no competitors. That seems interesting, and I don't think it would be that hard to add. I really like your ideas there, especially number 1, that's very smart. Number 2 is clever as well. > Who knows etc.. ORLY? Good to know.

by socmag 9y ago

nhaehnle 9y ago

I don't think that idea makes sense. A lot of stack space is unused at any particular time. There's not a one-size-fits-all partition that makes sense, and it's not something that programs could easily tune either. Some obvious stack-related ideas that are worth exploring IMHO are (1) using the stack pointer to guide the prefetcher, to run ahead of cache misses when you return from subroutines and go up the stack; and (2) having an instruction that helps avoid unneeded cache misses when going down the stack; for example, a dedicated instruction for decrementing the stack pointer which zeros entire cache lines directly in L1 without loading them. Or perhaps, for more generality, an instruction for marking any arbitrary address range in this way. Who knows, at least the first one might already be in use in some microarchitectures!

socmag 9y ago
Yes I agree that a lot of stack space goes unused right now, that is for sure, but the nice thing about the stack it is definitely thread/core local, and if you did have fast-stack capability we would definitely use it. What I was thinking about was a separate bus to a per thread stack space with no competitors. That seems interesting, and I don't think it would be that hard to add. I really like your ideas there, especially number 1, that's very smart. Number 2 is clever as well. > Who knows etc.. ORLY? Good to know.