Title: Rust Brain Teasers, page 47
“Because of the extra steps required for heap read/write access—particularly with frequent allocations—accessing data on the heap can be a lot slower than accessing data on the stack. Why? Because the CPU’s memory cache will try its best to keep your heap data available.”
This explanation doesn’t really make sense - both heap and stack are cached, and in both cases “the memory cache will try its best”. I think this might be trying to say something about stack memory has better locality, so the cache has an easier job, but even so, the above paragraph struck me as misleading and/or confusing.
Thank you! I’m inclined to agree, I’ll see if I can make that explanation a bit clearer for the next beta.
There’s really two things at play with stack vs. heap cache. One is locality: your stack is almost always in one of the cache levels because your program uses it constantly. The stack being tiny also helps with this: it’s easy to fit into the cache, so there’s an even higher probability that it will be there (and if it isn’t, it’s a fast operation to load a tiny stack frame into cache vs. an arbitrarily sized heap object).
Good catch - thank you. 
1 Like
Yay - glad to help! While I’m here, I think the previous paragraph is also confusing:
“Reading data from the heap also requires a little more work: to read data, your program first needs to read the pointer to determine where the heap data is stored. Once it knows the location, the program can read the data from there.”
It’s confusing (to me) - accessing the stack is also via a pointer, and usually accessing the stack involves computing an offset from the stack pointer first, so…it’s not cut-and-dried easier.
One aspect of the difference between them that your discussion doesn’t yet capture is that allocating from the stack is super-cheap (moving the SP), where it’s almost rocket science what goes on in modern heap allocators.
I’m really enjoying the book so far - I’ve learned a lot already!
1 Like
I’ll see if I can get that clarified, too. I have to try and keep the page count under control (my first draft went into “what is a stack, how does it work?” and was FAR too long for the format). Thanks again!
