Michael S <
already5chosen@yahoo.com> writes:
On Tue, 5 Mar 2024 22:58:10 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
On Tue, 5 Mar 2024 11:11:03 +0200, Michael S wrote:
>
On Tue, 5 Mar 2024 01:54:46 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
Discord did some benchmarking of its back-end servers, which had
been using Go, and decided that switching to Rust offered better
performance.
>
- for big and complex real-world back-end processing, writing
working solution in go will take 5 time less man hours than
writing it in Rust
>
Nevertheless, they found the switch to Rust worthwhile.
>
I read a little more about it.
https://discord.com/blog/why-discord-is-switching-from-go-to-rust
>
Summary: performance of one of Discord's most heavy-duty servers
suffered from weakness in implementation of Go garbage collector.
[...]
>
I have few questions about the story, most important one is
whether the weakness of this sort is specific to GC of Go, due
to its relative immaturity or more general and applies equally
to most mature GCs on the market, i.e. J2EE and .NET.
After reading the article, it seems clear that the design of the
GC used in Go is not a good fit to the Discord server workload.
That is not to say that Go's GC would be a bad fit for other
workloads, only that it's not a good choice for the Discord
server. Also it seems clear that other approaches to GC design
(meant in the sense of already having been thought of and tried)
would be just fine for the Discord server. Of course whether
such schemes would be a good fit for the Go environment is
a separate question (and one about which I have nothing to
offer since I know very little about Go).
Another question is whether the problem is specific to GC-style
of automatic memory management (AMM) or applies, at least to
some degree, to other forms of AMM, most importantly, to AMMs
based on Reference Counting used by Swift and also popular in
C++.
It's very hard to make a blanket statement that applies to all
the different approaches to garbage collection, or to other
automatic memory management schemes (with reference counting as a
specific example), in a general way. My experience with garbage
collected environments is that they are perfectly usable both for
long-term use and for interactive use. Reference counting too:
typically RC gives a smoother feel, but that comes at a cost,
because RC does not, by itself, reclaim circular structures.
That means that either, one, code must be written to break the
circularity of such structures (so memory management is not fully
automated); or two, periodically some sort of more general GC
method must be invoked to reclaim them; or three, eventually
more and more memory is used to where the application must be
rebooted (like the memory usage patterns of some popular web
browsers). The question is what kind of workloads need to be
supported - some schemes are good for typical interactive, but
short-term, applications, other schemes are better for the sort
of long-term server processes like the Discord example. The
space of already existing techniques for doing GC is pretty
large - if a particular kind of workload needs to be supported,
there is a very good chance that an appropriate GC scheme can
be found without much difficulty.
Incidentally, there is no such thing as a fully automatic memory
management system. Even full garbage collection sometimes needs
help from the programmer so all memory is eventually reclaimed.
(If you're feeling brave try doing a web search for "ephemeron".)
The point of all AMM schemes is not to reduce the amount of
programmer effort to zero but simply to greatly reduce it (and
hopefully reduce it to zero in many of the most common cases).
But for complicated programs it's almost inevitable that some
programmer-written code needs to be included to help whatever
automated mechanisms are used.
Of course, I don't expected that my questions will be answered
fully on comp.lang.c, but if some knowledgeable posters will try
to answer I would appreciate.
The questions presented were somewhat general, and so the answers
given are also rather general. In spite of that I hope you found
what you're looking for.
Re: "White House to Developers: Using C or C++ Invites Cybersecurity Risks"