This is a good introduction to RCU, but many of the arguments in favour of GC are simply wrong or straw-man. The good part of the post ends in the "Wat" section.
> And it’s an interesting example that cuts against the prevailing wisdom that garbage collection is:
> Slower than manual memory management
> Takes away the fine-grained control you need when writing systems software
> These arguments are clearly bullshit for RCU
But not all garbage collection is RCU. The "prevailing wisdom" is still valid.
> which is motivated by performance and latency demands, not used as a convenience in spite of its costs.
But that's not how GC is used most of the time. I haven't seen a C++ programmer carefully opt into GC for a subset of their allocations even though there are GC libraries written for the language. Rather, somebody designs a language and bolts GC into it for convenience and in spite of its costs.
> malloc() is not magically fast
> free() is not free
Whoever made that claim? Gamedevs particulary have been writing custom memory allocators since decades precisely because they know free() is not free and malloc() isn't fast.
> Modern garbage collection offers optimizations that alternatives can not.
Sure, on top of its costs.
> The Illusion of Control
It's not an illusion, you literally use control over memory management.
> They want to go as fast as possible—more FPS in my video game!
Actually, no. What they don't want is random stalls in odd frames. The concern here is reproducible and predictable latency (time per frame), not throughput (fps). It's also the same concern people bring in the web service / distributed system space, although I am not particularly in that spot; it's that 0.01% tail of abnormal latency spikes that bothers them, not the throughput of the system.
> Lies people believe about memory management
Nobody believes any of these points. I dislike posts that make claims about what others believe when it's usually just the author believing it themselves.
> I haven't seen a C++ programmer carefully opt into GC for a subset of their allocations even though there are GC libraries written for the language.
Can you give an example of such GC libraries?
> Whoever made that claim? Gamedevs particulary have been writing custom memory allocators since decades precisely because they know free() is not free and malloc() isn't fast.
Game developers use engines based on the GC.
> It's not an illusion, you literally use control over memory management.
The shared_ptr does not provide full control.
> What they don't want is random stalls in odd frames.
You can have fully concurrent GC, without any stalls.
This is a good introduction to RCU, but many of the arguments in favour of GC are simply wrong or straw-man. The good part of the post ends in the "Wat" section.
> And it’s an interesting example that cuts against the prevailing wisdom that garbage collection is:
> Slower than manual memory management
> Takes away the fine-grained control you need when writing systems software
> These arguments are clearly bullshit for RCU
But not all garbage collection is RCU. The "prevailing wisdom" is still valid.
> which is motivated by performance and latency demands, not used as a convenience in spite of its costs.
But that's not how GC is used most of the time. I haven't seen a C++ programmer carefully opt into GC for a subset of their allocations even though there are GC libraries written for the language. Rather, somebody designs a language and bolts GC into it for convenience and in spite of its costs.
> malloc() is not magically fast > free() is not free
Whoever made that claim? Gamedevs particulary have been writing custom memory allocators since decades precisely because they know free() is not free and malloc() isn't fast.
> Modern garbage collection offers optimizations that alternatives can not.
Sure, on top of its costs.
> The Illusion of Control
It's not an illusion, you literally use control over memory management.
> They want to go as fast as possible—more FPS in my video game!
Actually, no. What they don't want is random stalls in odd frames. The concern here is reproducible and predictable latency (time per frame), not throughput (fps). It's also the same concern people bring in the web service / distributed system space, although I am not particularly in that spot; it's that 0.01% tail of abnormal latency spikes that bothers them, not the throughput of the system.
> Lies people believe about memory management
Nobody believes any of these points. I dislike posts that make claims about what others believe when it's usually just the author believing it themselves.
> I haven't seen a C++ programmer carefully opt into GC for a subset of their allocations even though there are GC libraries written for the language.
Can you give an example of such GC libraries?
> Whoever made that claim? Gamedevs particulary have been writing custom memory allocators since decades precisely because they know free() is not free and malloc() isn't fast.
Game developers use engines based on the GC.
> It's not an illusion, you literally use control over memory management.
The shared_ptr does not provide full control.
> What they don't want is random stalls in odd frames.
You can have fully concurrent GC, without any stalls.