On Sunday, 7 August 2022 at 21:25:57 UTC, ryuukk_ wrote:
> On Sunday, 7 August 2022 at 21:17:50 UTC, max haughton wrote:
> On Sunday, 7 August 2022 at 20:43:32 UTC, ryuukk_ wrote:
> On Sunday, 7 August 2022 at 17:23:52 UTC, Paulo Pinto wrote:
> [...]
That's kinda bullshit, it depends on the GC implementation
D's GC is not good for 99.99% "of all software in the world", it's wrong to say this, and is misleading
Java's ones are, because they offer multiple implementations that you can configure and the, they cover a wide range of use cases
D's GC is not the panacea, it's nice to have, but it's not something to brag about, specially when it STILL stop the world during collection, and is STILL not scalable
Go did it right by focusing on low latency, and parallelism, we should copy their GC
It's actually 69.420% of all software in the world
Exactly, hence why this quote is bullshit
But nobody wants to understand the problems anymore
https://discord.com/blog/why-discord-is-switching-from-go-to-rust
Let's miss every opportunities to catch market shares
I don't see how that is related. According to the investigation they described in the article you linked, Go's GC is set up to run every 2 minutes no questions asked. That's not true for D's GC.
Instead of jumping on the rust hype train they could have forked Go's GC and solved the actual performance problem - the forced 2 minutes GC run.
As far as D's default GC is concerned. Last time I checked it only runs a collection cycle on an allocation, further, once the GC has allocated the memory from the OS it won't release it back until the program terminates.
This means that the GC can re-alloc previously allocated, but now collected, memory basically for free, because there's not context switch into kernel and back. Which may have additional cost of reloading cache lines. But all of this depends on a lot of factors so this may or may not be a big deal.
Also, when you run your own memory management, you need to keep in mind that your manual call to *alloc/free is just as expensive as if the GC calls it. You also need to keep in mind that your super fast allocator (as in the lib/system call you use to allocate the memory) may not actually allocate the memory on your call but the real allocation may be deferred until such time when the memory is actually accessed, which may cause lag akin to that of a collection cycle, depending on the amount of memory you allocate.
It's possible to pre-allocate memory with a GC. Re-use those buffers, and slice them as you see fit. Without ever triggering a collection cycle.
You can also disable garbage collection for D'c GC for hot areas.
IME the GC saves a lot of headaches, much more than it causes and I'd much rather have more convenience in communicating my intentions to the GC than cluttering every API with allocator parameters.
Something like:
@GC(DND)//Do Not Disturb
{
foreach (...)
// hot code goes here and no collection cycles will happen
}
or,
void load_assets()
{
// allocate, load stuff, etc..
@GC(collect); // lag doesn't matter here
}