Sure, writing these system in a non-GC language is harder but that's not really what is talked about here right? There is a reason why databases are not really successful in Java for example. Caching software are predominantly in C/C++. Beating highly tuned C/C++ is not something that a GC can do by itself. What it brings is convenience and frankly it's "good enough" for most cases. We shouldn't pretend that GC is be all end all to both developer and runtime performance.
On Wed, Feb 12, 2020 at 2:10 PM Robert Engels <reng...@ix.netcom.com> wrote: > Aren’t we all all “students” :) > > The conclusions you cite are from the 2005 paper. > > I’m sure I can find other more recent peer reviewed papers that draw the > same conclusions as the “student” one. > > I don’t think it is necessary though. If you understand how malloc or > tcmalloc and how modern GC works you’ll also know why it’s the case. Even > with tcmalloc, highly concurrent dynamic memory systems are a problem > without GC. A simple example, with Rust dealloc a large dynamic object > graph vs a GC language- expensive vs cheap. > > On Feb 12, 2020, at 6:36 AM, Brian Candler <b.cand...@pobox.com> wrote: > > > On Wednesday, 12 February 2020 05:00:41 UTC, robert engels wrote: >> >> I found a more recent academic paper that proves my conclusions: >> >> >> https://www.researchgate.net/publication/326369017_From_Manual_Memory_Management_to_Garbage_Collection >> >> > It's a student paper. > > The bit that caught my eye was results of simulation using real Java > programs: > > *it’s been proven that the runtime performance of the best-performing > garbage collector is competitive with explicit memory management when given > enough memory. In particular, when garbage collection has five times as much > memory as required, its runtime performance matches or slightly exceeds > that of explicit memory management.* > > > *However, garbage collection’s performance degrades substantially when it > must use smaller heaps. With three times as much memory, it runs 17% slower > on average, and with twice as much memory, it runs 70% slower.* > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/230ed453-0897-48a7-8662-4807e7774e85%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/230ed453-0897-48a7-8662-4807e7774e85%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/EF2B49E6-2A39-4582-9308-84F5D35F91EA%40ix.netcom.com > <https://groups.google.com/d/msgid/golang-nuts/EF2B49E6-2A39-4582-9308-84F5D35F91EA%40ix.netcom.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAKOF697R-VmPxbjuP8%2BkFkO5J2M9JVKjK44qNX_Qb1AczZAHcA%40mail.gmail.com.
