4 ms·

Are you concerned about garbage collectors that do relocation/compaction or what? Otherwise garbage collection doesn't really effect much of what is discussed

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)?

phserr 12y ago
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.
- sliverstorm 12y ago
  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/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf http://research.scee.net/files/presentations/gcapaustralia09...
- voidlogic 12y ago
  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 < neededFoobars; i++ { seqfoobarPtrs[i] = &backingSlice[i] }
  - dbaupp 12y ago
    (FWIW, Rust is not garbage collected.)
    - voidlogic 12y ago
      Rust has optional garbage collection
      - FreeFull 12y ago
        There is a library type that does reference counting. It's not built into the language, beyond happening to be in the standard libraries.
      - dbaupp 12y ago
        It doesn't. There is a type called Gc that may be garbage collected in future, but at the moment it is just a bad reference counted pointer (the Rc type is better if you want reference counting). And it's not even guaranteed that a GC will ever be implemented, Rust provides other abstractions so GC would be rarely used even if it was implemented.

phserr 12y ago

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.

sliverstorm 12y ago
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/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf http://research.scee.net/files/presentations/gcapaustralia09...
voidlogic 12y ago
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 < neededFoobars; i++ { seqfoobarPtrs[i] = &backingSlice[i] }
- dbaupp 12y ago
  (FWIW, Rust is not garbage collected.)
  - voidlogic 12y ago
    Rust has optional garbage collection
    - FreeFull 12y ago
      There is a library type that does reference counting. It's not built into the language, beyond happening to be in the standard libraries.
    - dbaupp 12y ago
      It doesn't. There is a type called Gc that may be garbage collected in future, but at the moment it is just a bad reference counted pointer (the Rc type is better if you want reference counting). And it's not even guaranteed that a GC will ever be implemented, Rust provides other abstractions so GC would be rarely used even if it was implemented.