5 ms·

> How is the performance of D compared to other garbage collected languages when the garbage collector is turned on? The GC itself isn't very good. The overal

> How is the performance of D compared to other garbage collected languages when the garbage collector is turned on? The GC itself isn't very good. The overall language performance, though, is quite good; the allocator isn't usually a bottleneck.

WalterBright 6y ago
The GC could be improved by generating extra code when pointer accesses are made, so the GC can keep track of writes to GC allocated memory. This makes the GC faster and more effective, at the expense of slower generated code. It is a worthwhile tradeoff for fully GC languages like Java. But it isn't worthwhile for D, which uses GC here and there and a lot of non-GC pointers and allocations. D trades things off in the other direction - faster runtime code generation, at the cost of a slower GC.
- MaxBarraclough 6y ago
  > D, which uses GC here and there and a lot of non-GC pointers and allocations Won't this depend on the programming style used? If the programmer makes heavy use of functional programming, or for that matter Java-style programming, wouldn't that result in a lot of object churn through the GC?
  - mhh__ 6y ago
    Functional code as usually written in D doesn't have this problem because people are aware of this - most compositions are extremely lazy, allocations are trivial to group together because of allocators in the stdlib
  - WalterBright 6y ago
    Java does not have stack allocated objects like struct instances. They get allocated via the GC (sometimes the Java optimizer can optimize these to be stack allocated). Personally, I make very heavy use of stack allocated objects, even for temporary buffers. Stack allocated objects cost nothing to allocate, nothing to free, and (being on the stack) are already in the hot memory cache.
- moonchild 6y ago
  Why not add a separate, optional compilation mode that uses barriers?
  - WalterBright 6y ago
    To make it effective, you'd only want it to apply to GC pointers. But the type system does not distinguish between GC pointers and other pointers, making such a mode a rather complex implementation problem.
    - moonchild 6y ago
      In java-like situations where something like that would see use, I think it would be fair to treat all pointers as gc pointers.
      - WalterBright 6y ago
        In Java, all pointers are GC pointers. But in D, not very many are. For example, objects on the stack aren't GC pointers.
        moonchild 6y ago
        Objects on the stack aren't pointers at all...
        WalterBright 6y ago
        If you have a struct on the stack, and call member functions, you've got pointers. For an array on the stack, taking a slice of it or looping through it with pointers, you've got pointers. For a variable on the stack, passing it by ref to another function, there are pointers.
- Shadonototro 6y ago
  The problem of D GC is it doesn't scale at all The more pointers you need to scan, the slower it becomes, and it'll stop all threads It's fine for a compiler or a cli tool, but it's very bad for anything that runs forever and needs to scale (server and games, specially networked games where the world and number of entities is not fixed) you then need to think about managing your memory and working around the GC a lot; then you think about yourself, why use GC at all.. D needs invest more into non GC stuff and making the GC trully optional, make it possible to link the GC away if you don't need it, make the runtime less dependent on GC (ability to statically make GC usages assert such as 'new', rework associative array, and cleanup the runtime from requiring GC, thread, socket etc etc etc) I use D everyday, i know how to deal with that kind of issue, but new people don't, and they might be turned off the day they need to workaround GC issues
  - bsdooby 6y ago
    Dare to elaborate how you manage these GC issues (example code, howtos, etc.)? Thx

WalterBright 6y ago

The GC could be improved by generating extra code when pointer accesses are made, so the GC can keep track of writes to GC allocated memory. This makes the GC faster and more effective, at the expense of slower generated code. It is a worthwhile tradeoff for fully GC languages like Java. But it isn't worthwhile for D, which uses GC here and there and a lot of non-GC pointers and allocations. D trades things off in the other direction - faster runtime code generation, at the cost of a slower GC.

MaxBarraclough 6y ago
> D, which uses GC here and there and a lot of non-GC pointers and allocations Won't this depend on the programming style used? If the programmer makes heavy use of functional programming, or for that matter Java-style programming, wouldn't that result in a lot of object churn through the GC?
- mhh__ 6y ago
  Functional code as usually written in D doesn't have this problem because people are aware of this - most compositions are extremely lazy, allocations are trivial to group together because of allocators in the stdlib
- WalterBright 6y ago
  Java does not have stack allocated objects like struct instances. They get allocated via the GC (sometimes the Java optimizer can optimize these to be stack allocated). Personally, I make very heavy use of stack allocated objects, even for temporary buffers. Stack allocated objects cost nothing to allocate, nothing to free, and (being on the stack) are already in the hot memory cache.
moonchild 6y ago
Why not add a separate, optional compilation mode that uses barriers?
- WalterBright 6y ago
  To make it effective, you'd only want it to apply to GC pointers. But the type system does not distinguish between GC pointers and other pointers, making such a mode a rather complex implementation problem.
  - moonchild 6y ago
    In java-like situations where something like that would see use, I think it would be fair to treat all pointers as gc pointers.
    - WalterBright 6y ago
      In Java, all pointers are GC pointers. But in D, not very many are. For example, objects on the stack aren't GC pointers.
      - moonchild 6y ago
        Objects on the stack aren't pointers at all...
        WalterBright 6y ago
        If you have a struct on the stack, and call member functions, you've got pointers. For an array on the stack, taking a slice of it or looping through it with pointers, you've got pointers. For a variable on the stack, passing it by ref to another function, there are pointers.
Shadonototro 6y ago
The problem of D GC is it doesn't scale at all The more pointers you need to scan, the slower it becomes, and it'll stop all threads It's fine for a compiler or a cli tool, but it's very bad for anything that runs forever and needs to scale (server and games, specially networked games where the world and number of entities is not fixed) you then need to think about managing your memory and working around the GC a lot; then you think about yourself, why use GC at all.. D needs invest more into non GC stuff and making the GC trully optional, make it possible to link the GC away if you don't need it, make the runtime less dependent on GC (ability to statically make GC usages assert such as 'new', rework associative array, and cleanup the runtime from requiring GC, thread, socket etc etc etc) I use D everyday, i know how to deal with that kind of issue, but new people don't, and they might be turned off the day they need to workaround GC issues
- bsdooby 6y ago
  Dare to elaborate how you manage these GC issues (example code, howtos, etc.)? Thx