4 ms·

> Any malloc'd pointer will look just like a GC pointer, so you'll be paying the penalty for all of those. I don't see why. A small amount of manual tagging f

> Any malloc'd pointer will look just like a GC pointer, so you'll be paying the penalty for all of those. I don't see why. A small amount of manual tagging for extern(C) things—done in this case as part of the standard library, so opaque to user code—will go a long way in that regard. And in any custom allocator, automatic inference should work just fine, since the data returned will be clearly derived from the already-tagged malloc/mmap/VirtuallAlloc/whatever (type info does still have to be associated manually, of course, as part of the GC.addRange dance, to avoid spurious pinning).

WalterBright 4y ago
That would all come undone with separate compilation. You'd have to recompile the entire program every time. You'd also have to keep around a massive amount of data at compile time. A variable that's a pointer to a struct, can't just be represented as a pointer to a struct. It'd have to have a map of which pointers in the struct are managed for every pointer to that struct. The way the D compiler is implemented now, a struct S has only one instance, as every pointer to a struct's type points to that same instance. And still sometimes people compile programs so large the compiler runs out of memory.
- moonchild 4y ago
  You were complaining about 1% performance deltas else-thread—anyone remotely serious about performance is using LTO.
  - z3c0 4y ago
    If you were going to debate in a public forum, you should have anticipated some pedantic loser like myself coming along and pointing out your No True Scotsman fallacy.
  - simplotek 4y ago
    > You were complaining about 1% performance deltas else-thread (...) You should revisit that corner of the thread to revive your memory. The discussion was about adding an extra 1% performance penalty for reasons, not the importance of a 1% delta either way.

4 ms·

> Any malloc'd pointer will look just like a GC pointer, so you'll be paying the penalty for all of those. I don't see why. A small amount of manual tagging f

by moonchild 4y ago

WalterBright 4y ago
That would all come undone with separate compilation. You'd have to recompile the entire program every time. You'd also have to keep around a massive amount of data at compile time. A variable that's a pointer to a struct, can't just be represented as a pointer to a struct. It'd have to have a map of which pointers in the struct are managed for every pointer to that struct. The way the D compiler is implemented now, a struct S has only one instance, as every pointer to a struct's type points to that same instance. And still sometimes people compile programs so large the compiler runs out of memory.
- moonchild 4y ago
  You were complaining about 1% performance deltas else-thread—anyone remotely serious about performance is using LTO.
  - z3c0 4y ago
    If you were going to debate in a public forum, you should have anticipated some pedantic loser like myself coming along and pointing out your No True Scotsman fallacy.
  - simplotek 4y ago
    > You were complaining about 1% performance deltas else-thread (...) You should revisit that corner of the thread to revive your memory. The discussion was about adding an extra 1% performance penalty for reasons, not the importance of a 1% delta either way.