Future of memory management in D
tchaloupka
chalucha at gmail.com
Wed Nov 17 16:03:29 UTC 2021
On Wednesday, 17 November 2021 at 13:44:39 UTC, Adam D Ruppe
wrote:
> On Wednesday, 17 November 2021 at 12:14:46 UTC, tchaloupka
> wrote:
>> * it's hard to tell anyone that GC in D is fine when you look
>> at techempower benchmark and searching the vibe-d (or anything
>> in D) somewhere up where it should be and isn't (event other
>> GC languages are much higher there)
>
> I'm pretty sure you're the one who benchmarked my cgi.d and it
> annihilated vibe.d in that test.
>
> Maybe it isn't the GC and vibe is just poorly written?
Yeah, that was me ;-)
In case of the techempower one problem with GC is, that it is
tested on a CPU with many cores. For each of them there is one
thread to manage clients (using `SO_REUSEADDR`/`SO_REUSEPORT`).
There would be a problem with a `stop the world` GC as it would
stop all of them. In case of the web server there would be better
to use some allocator that just allocates as needed in a scope of
currently handled request and discards all of it back on request
completion. Something like this is used in nginx module
implementation for example.
Or one would need to manage a set of subprocesses to avoid others
to be stopped on GC collection.
But then you'll start making workarounds for the GC, start to
manage memory manually here and there and then you realize that
you would probably be better without the GC in the first place.
Sometimes it just won't scale.
GC would also add some syscalls overhead as it uses signals,
eventfd, etc.
Of course there would also be places in vibe that are suboptimal,
it's not only about the GC. Maybe even fibers alone won't be as
lightweight compared to rust/c++. Rust has also a stealing
scheduler with waitfree/lockfree queues.
More information about the Digitalmars-d
mailing list