Re:Cache Lines Are The New Registers
by csense on Sunday September 02, 2012 @06:46PM
(#4468422)
The article's last point is a little questionable:
> compilers could defer stack usage in favor of a reserved area of program memory for temporary values, that has a very high likelihood of always being in cache.
"A reserved area of program memory for temporary values, that has a very high likelihood of always being in cache" -- this is a fair definition of the stack.
> the stack is function-local.
Depends on your definition of "function-local". Yes, variables local to an individual function are stored on the stack, but the stack frames for multiple function calls are adjacent in memory. It's not like entering or exiting a function will always switch to a different cache line. Someone who looks at "disassembly of optimized code in the wild" should be well aware of this.
> For temporaries that don’t need to persist past calls to other functions, some performance could be gained by avoiding cache misses on stack memory that isn’t going to be used after the function returns anyway.
You should be able to achieve this in the current world with aggressive use of scopes to explicitly expire particular locals before the end of a function, or use of inline functions.
It is an idea for a compiler optimization, however: Expire a local variable at the last point it is used in a function. There are a number of subtleties though: The compiler would have to be able to reorder local variables to make sure the expirable ones are at the top of stack when they expire, would have to mark variables for which pointers are taken non-expirable (unless the pointers themselves, or values derived from them, themselves don't escape the function), and would make stack frames more complicated to parse for debuggers and backtrace displays.
> compilers could defer stack usage in favor of a reserved area of program memory for temporary values, that has a very high likelihood of always being in cache.
"A reserved area of program memory for temporary values, that has a very high likelihood of always being in cache" -- this is a fair definition of the stack.
> the stack is function-local.
Depends on your definition of "function-local". Yes, variables local to an individual function are stored on the stack, but the stack frames for multiple function calls are adjacent in memory. It's not like entering or exiting a function will always switch to a different cache line. Someone who looks at "disassembly of optimized code in the wild" should be well aware of this.
> For temporaries that don’t need to persist past calls to other functions, some performance could be gained by avoiding cache misses on stack memory that isn’t going to be used after the function returns anyway.
You should be able to achieve this in the current world with aggressive use of scopes to explicitly expire particular locals before the end of a function, or use of inline functions.
It is an idea for a compiler optimization, however: Expire a local variable at the last point it is used in a function. There are a number of subtleties though: The compiler would have to be able to reorder local variables to make sure the expirable ones are at the top of stack when they expire, would have to mark variables for which pointers are taken non-expirable (unless the pointers themselves, or values derived from them, themselves don't escape the function), and would make stack frames more complicated to parse for debuggers and backtrace displays.