4 ms·

I actually find it one of the biggest downfalls of D. IMO, you have to pick one, among other things for what's listed in the article. Riding the fence leads t

I actually find it one of the biggest downfalls of D. IMO, you have to pick one, among other things for what's listed in the article. Riding the fence leads to a worse experience for both sides.

masklinn 4y ago
> Riding the fence leads to a worse experience for both sides. I don't entirely agree, I think having a garbage collected pointer (GCP) can make a lot of sense as a performance optimisation: manual memory management (MMM) and reference counting (RC) have stampeding characteristics similar to GC pauses when releasing large hierarchies e.g. persistent data structures, or large trees of widgets: all the tree is freed synchronously and recursively, if it's large it can be very sensible. This stampeding is more predictable than a GC pause, but it's no less problematic when it occurs, and mitigating it can be difficult (you have to manually shunt the objects you'd like to release off-thread). A GCP can do that shunting on its own, letting a GC thread perform the releases asynchronously, and piecemeal. Furthermore, GCP means you're not expecting to precisely track allocations at the system level, which means the usual tricks (arenas, bump allocators, ...) can be applied by default to GC pointers, where they usually can't be to MMM or RC pointers. This decreases allocation and deallocation overhead by reducing the amount of work the system has to do.
- pjmlp 4y ago
  Hence why other languages do make this differentiation, only D refuses to go down this path.
- zozbot234 4y ago
  > you have to manually shunt the objects you'd like to release off-thread. A GCP can do that shunting on its own, letting a GC thread perform the releases asynchronously, and piecemeal. You could also use async programming to do the same thing in GC-free code. Or just use an arena that can be freed all at once.
  - masklinn 4y ago
    > You could also use async programming to do the same thing in GC-free code. No? Allocations are blocking, "async programming" won't do anything. Unless you have an async dealloc which does the shunting implicitly, at which point you don't need an async dealloc, you can just have a sync one which shunts the actual dealloc and mandate a background thread. Which means now you're mandating a background thread for freeing memory. And you hope that the load is light enough that implicit thread which you've tasked with all deallocations (rather than just the ones which make sense) keeps up. > Or just use an arena that can be freed all at once. That is essentially the same thing, you now have a different allocation strategy for these, except it's a lot more limited and specific.
    - SleepyMyroslav 4y ago
      > No? Allocations are blocking, Modern malloc/free implementations must satisfy requirements such as being scalable. It eliminates any chance to implement blocking deallocation from non-owner threads. A modern implementation already has to be async in some ways. You can check paper behind Mimalloc for example.
  - kaba0 4y ago
    An arena allocator presupposes a huge number of objects each having the same lifecycle - which is not all that common/general.
    - generichuman 4y ago
      > which is not all that common/general. Your objects in trees and arrays don't have the same lifecycle? Quoting GP: > ... reference counting (RC) have stampeding characteristics similar to GC pauses when releasing large hierarchies e.g. persistent data structures, or large trees of widgets: all the tree is freed synchronously and recursively, if it's large it can be very sensible. This is mostly where RC & MMM fails. This is also where you are supposed to use arena allocators. If you have a tree you're constantly adding to / deleting from, you can use a Pool backed by an Arena. At that point you don't use pointers, only indices into the pool. When you want to remove something from the tree, you mark the objects in the pool "deleted" until you want something added back again.
WalterBright 4y ago
> I actually find it one of the biggest downfalls of D. Why? The gc is optional in D. You can use malloc/free, or your own custom allocator.
skocznymroczny 4y ago
I agree about riding the fence. The main reason D is so criticised for having a GC because it gives users a choice. I'd also rather have it either go full GC or full manual/semi-manual memory management, probably leaning more towards GC side personally. There are other aspects where D gets hit from both sides because it never picks a side, instead it tries to cater to both sides, never going full into any of them. I guess there is some benefit in a language that's general and doesn't force you into specific paradigms, but it also increases the surface area (maintenance area) of the language and adds complexity for developers when every step of the way you have to consider the alternatives.
- WalterBright 4y ago
  D obviates the need to use different languages for different parts of an application, by supporting multiple paradigms.
ErikCorry 4y ago
Agreed that riding the fence doesn't give a satisfactory result. In theory, GC is optional in Go, but I don't think anyone seriously running without a GC, or writing code that works well without a GC.

I actually find it one of the biggest downfalls of D. IMO, you have to pick one, among other things for what's listed in the article. Riding the fence leads to a worse experience for both sides.

masklinn 4y ago

> Riding the fence leads to a worse experience for both sides. I don't entirely agree, I think having a garbage collected pointer (GCP) can make a lot of sense as a performance optimisation: manual memory management (MMM) and reference counting (RC) have stampeding characteristics similar to GC pauses when releasing large hierarchies e.g. persistent data structures, or large trees of widgets: all the tree is freed synchronously and recursively, if it's large it can be very sensible. This stampeding is more predictable than a GC pause, but it's no less problematic when it occurs, and mitigating it can be difficult (you have to manually shunt the objects you'd like to release off-thread). A GCP can do that shunting on its own, letting a GC thread perform the releases asynchronously, and piecemeal. Furthermore, GCP means you're not expecting to precisely track allocations at the system level, which means the usual tricks (arenas, bump allocators, ...) can be applied by default to GC pointers, where they usually can't be to MMM or RC pointers. This decreases allocation and deallocation overhead by reducing the amount of work the system has to do.

pjmlp 4y ago
Hence why other languages do make this differentiation, only D refuses to go down this path.
zozbot234 4y ago
> you have to manually shunt the objects you'd like to release off-thread. A GCP can do that shunting on its own, letting a GC thread perform the releases asynchronously, and piecemeal. You could also use async programming to do the same thing in GC-free code. Or just use an arena that can be freed all at once.
- masklinn 4y ago
  > You could also use async programming to do the same thing in GC-free code. No? Allocations are blocking, "async programming" won't do anything. Unless you have an async dealloc which does the shunting implicitly, at which point you don't need an async dealloc, you can just have a sync one which shunts the actual dealloc and mandate a background thread. Which means now you're mandating a background thread for freeing memory. And you hope that the load is light enough that implicit thread which you've tasked with all deallocations (rather than just the ones which make sense) keeps up. > Or just use an arena that can be freed all at once. That is essentially the same thing, you now have a different allocation strategy for these, except it's a lot more limited and specific.
  - SleepyMyroslav 4y ago
    > No? Allocations are blocking, Modern malloc/free implementations must satisfy requirements such as being scalable. It eliminates any chance to implement blocking deallocation from non-owner threads. A modern implementation already has to be async in some ways. You can check paper behind Mimalloc for example.
- kaba0 4y ago
  An arena allocator presupposes a huge number of objects each having the same lifecycle - which is not all that common/general.
  - generichuman 4y ago
    > which is not all that common/general. Your objects in trees and arrays don't have the same lifecycle? Quoting GP: > ... reference counting (RC) have stampeding characteristics similar to GC pauses when releasing large hierarchies e.g. persistent data structures, or large trees of widgets: all the tree is freed synchronously and recursively, if it's large it can be very sensible. This is mostly where RC & MMM fails. This is also where you are supposed to use arena allocators. If you have a tree you're constantly adding to / deleting from, you can use a Pool backed by an Arena. At that point you don't use pointers, only indices into the pool. When you want to remove something from the tree, you mark the objects in the pool "deleted" until you want something added back again.

WalterBright 4y ago

> I actually find it one of the biggest downfalls of D. Why? The gc is optional in D. You can use malloc/free, or your own custom allocator.

skocznymroczny 4y ago

I agree about riding the fence. The main reason D is so criticised for having a GC because it gives users a choice. I'd also rather have it either go full GC or full manual/semi-manual memory management, probably leaning more towards GC side personally. There are other aspects where D gets hit from both sides because it never picks a side, instead it tries to cater to both sides, never going full into any of them. I guess there is some benefit in a language that's general and doesn't force you into specific paradigms, but it also increases the surface area (maintenance area) of the language and adds complexity for developers when every step of the way you have to consider the alternatives.

WalterBright 4y ago
D obviates the need to use different languages for different parts of an application, by supporting multiple paradigms.

ErikCorry 4y ago

Agreed that riding the fence doesn't give a satisfactory result. In theory, GC is optional in Go, but I don't think anyone seriously running without a GC, or writing code that works well without a GC.