3 ms·
I'm pretty sure this is still the case. I'm not sure how cross-platform that assumption is (it won't work in Go where it has heapstacks I don't think), but clas
by xena 3y ago
I'm pretty sure this is still the case. I'm not sure how cross-platform that assumption is (it won't work in Go where it has heapstacks I don't think), but classically yeah the stack is put is slightly faster memory with fewer access barriers.
- comex 3y agoI believe that’s inaccurate, at least on a modern CPU. The bookkeeping for the stack is faster, since ‘allocating’ and ‘deallocating’ is just subtracting from and adding to a register. And the area of the stack in active use at any given time is usually tiny (well under a kilobyte, even though the full stack is usually several megabytes), so it’s likely to stick around in L1 cache. And return addresses on the stack get special treatment by the branch predictor. But other than that, it’s treated the same as any other memory.