CPU Cache Essentials
meta-x86.blogspot.com
CPU Cache Essentials
1–10 of 19 posts
Re: CPU Cache Essentials
#2Direct link to the original presentation by Scott Meyers: http://vimeo.com/97337258 (the article is just a summary)
Re: CPU Cache Essentials
#3Seems obligatory to link to "Memory part 2: CPU caches" [1] from Ulrich Drepper's "What every programmer should know about memory" [2].
Re: CPU Cache Essentials
#4I see cache related optimizations being discussed most often in the context of C or C++. Being inexperienced in this area, I wonder how would does it affect garbage collected languages/systems. I understand that that are different approaches to GC, but can someone recommend some discussion to read on this topic? (cache optimization either in GC development itself or in development with GC languages)
Re: CPU Cache Essentials
#5I see cache related optimizations being discussed most often in the context of C or C++. Being inexperienced in this area, I wonder how would does it affect garbage collected languages/systems. I understand that that are different approaches to GC, but can someone recommend some discussion to read on this topic? (cache optimization either in GC development itself or in development with GC languages)
Are you concerned about garbage collectors that do relocation/compaction or what? Otherwise garbage collection doesn't really effect much of what is discussed here (except of course if you are preempted by the GC running and it empties the cache of useful things (to you), but this is rare). Maybe when you talk about GC you mean the heap allocator (which of course is related but different)?
Re: CPU Cache Essentials
#6I see cache related optimizations being discussed most often in the context of C or C++. Being inexperienced in this area, I wonder how would does it affect garbage collected languages/systems. I understand that that are different approaches to GC, but can someone recommend some discussion to read on this topic? (cache optimization either in GC development itself or in development with GC languages)
Are you concerned about garbage collectors that do relocation/compaction or what? Otherwise garbage collection doesn't really effect much of what is discussed here (except of course if you are preempted by the GC running and it empties the cache of useful things (to you), but this is rare). Maybe when you talk about GC you mean the heap allocator (which of course is related but different)?
What I meant was just how having a less direct control over memory (like you do with c/c++) affects (edit: in a practical way) the efficiency of cache usage. Having less control means being unable to pack things together as much as one would want, but I'm sure sophisticated GC algorithms (relocating/compacting/generational/incremental) directly or indirectly deal with that somehow. As I said, I'm inexperienced with GC and my understanding of them is probably a bit naive.
Re: CPU Cache Essentials
#7Well when working with entities/objects you are not really getting more efficient at the cache level than an array. As seen in this example with array parsing.
Make sure to use simple arrays when you want to store some data, it's not just in C but it will work well in other languages as well including javascript, php, python, perl, etc
Because that's how processors algorithms are designed.
Re: CPU Cache Essentials
#8Earlier quoted context omitted.
Are you concerned about garbage collectors that do relocation/compaction or what? Otherwise garbage collection doesn't really effect much of what is discussed here (except of course if you are preempted by the GC running and it empties the cache of useful things (to you), but this is rare). Maybe when you talk about GC you mean the heap allocator (which of course is related but different)?
What I meant was just how having a less direct control over memory (like you do with c/c++) affects (edit: in a practical way) the efficiency of cache usage. Having less control means being unable to pack things together as much as one would want, but I'm sure sophisticated GC algorithms (relocating/compacting/generational/incremental) directly or indirectly deal with that somehow. As I said, I'm inexperienced with G…
From what I've read, the real worry with (for example) C++ is not whether you can control packing or memory ordering. The real worry is when you create data structures that are fundamentally cache-unfriendly. The compiler won't reachitect an object into other objects to make it more memory friendly.
Simple example from the slides on optimizing for the PlayStation 3; if your object is large and full of different data, you miss a lot and burn lots of cache space every time you access it because it is so large. If your object is small and just a collection of pointers, you burn little cache space when you load it, and data can be arranged more appropriately.
http://research.scee.net/files/presentations/gcapaustralia09...
Re: CPU Cache Essentials
#9Earlier quoted context omitted.
Are you concerned about garbage collectors that do relocation/compaction or what? Otherwise garbage collection doesn't really effect much of what is discussed here (except of course if you are preempted by the GC running and it empties the cache of useful things (to you), but this is rare). Maybe when you talk about GC you mean the heap allocator (which of course is related but different)?
What I meant was just how having a less direct control over memory (like you do with c/c++) affects (edit: in a practical way) the efficiency of cache usage. Having less control means being unable to pack things together as much as one would want, but I'm sure sophisticated GC algorithms (relocating/compacting/generational/incremental) directly or indirectly deal with that somehow. As I said, I'm inexperienced with G…
Just to you are aware, you are presenting a false dichotomy. There are plenty of languages that are both garbage collected and give you quite a bit of control about memory layout (D, Go, Rust, etc).
For example, in Go if I wanted have a slice of Foobar ([]Foobar) but wanted to have them allocated close to one another I could write:
const neededFoobars = 100
backingSlice := make([]Foobar, neededFoobars)
seqfoobarPtrs := make([]*Foobar, neededFoobars)
for i := 0; i Re: CPU Cache Essentials
#10Earlier quoted context omitted.
What I meant was just how having a less direct control over memory (like you do with c/c++) affects (edit: in a practical way) the efficiency of cache usage. Having less control means being unable to pack things together as much as one would want, but I'm sure sophisticated GC algorithms (relocating/compacting/generational/incremental) directly or indirectly deal with that somehow. As I said, I'm inexperienced with G…
Just to you are aware, you are presenting a false dichotomy. There are plenty of languages that are both garbage collected and give you quite a bit of control about memory layout (D, Go, Rust, etc). For example, in Go if I wanted have a slice of Foobar ([] Foobar) but wanted to have them allocated close to one another I could write: const neededFoobars = 100 backingSlice := make([]Foobar, neededFoobars) seqfoobarPtrs…
(FWIW, Rust is not garbage collected.)