Re: [go-nuts] Go without garbage collector

[Robert Engels]

GCs have radically improved since then - at least in practical implementation.

Again, see G1, Metronome, Zing or Shenandoah - none of these were available in 2005.

(Or even Go's GC performance progression - but as I mentioned, in this particular test the lack of a generational collector is holding it back).

-----Original Message-----
From: alex.besogo...@gmail.com
Sent: Feb 12, 2020 3:06 PM
To: golang-nuts
Subject: Re: [go-nuts] Go without garbage collector

I'm very familiar with this paper. It's not the first one that uses oracular memory management for comparison, the earlier one used ML as its langauge.

The problem with these papers is that they're using very artificial benchmarks, not really representative of real workloads. They additionally use languages that are very heap-oriented, with very few value objects.

GCs also have not radically improved since then, if anything they are worse now in massively-parallel environment than on single-core CPUs of yore.

On Tuesday, February 11, 2020 at 8:54:29 PM UTC-8, robert engels wrote:

Here is a paper from 2005 https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf that proves otherwise.

GC techniques have radically improved since then, some with hardware support, so much so that it is no longer a contest.

To reiterate though, if you don’t have dynamic memory management - which is essentially allocate and forget - that will “probably" be faster (many GC systems have an extra level of indirection).

You can write robust systems without dynamic memory, but it is very very difficult - beyond the skills of most developers.

So most developers resort to dynamic memory at some point - and once you do that - GC will crush your manual memory management techniques.

On Feb 11, 2020, at 10:31 PM, alex.b...@gmail.com wrote:

Actually, it was not proven. And in practice manual memory management seems to be outperforming GC in majority of cases.

On Tuesday, February 11, 2020 at 5:59:26 PM UTC-8, robert engels wrote:

It’s been PROVEN that GC outperforms all manual memory management except in EXTREMELY isolated cases (very non-traditional allocation or deallocation patterns).

It’s all about constraints and tolerances.

You design a “system” that takes both into account - if not, you’re not engineering, you're guessing.

On Feb 11, 2020, at 4:29 AM, deat...@gmail.com wrote:

What about #vlang ? https://vlang.io/

On Sunday, 17 June 2012 22:40:30 UTC+2, nsf wrote:

On Sun, 17 Jun 2012 11:48:53 -0700 (PDT)
⚛ <0xe2.0...@gmail.com> wrote:

> > You can't have Go syntax without a garbage collector.
> >
>
> I wouldn't be so sure about it.
>  

Let me rephrase myself. When someone says "I want Go without garbage
collection" it means a person wants a feel he has with Go, but at the
same time without garbage collection. At least that's my case. I wanted
exactly that. And you can't have that. You can build a language similar
to Go without GC, but you won't get a feel of Go. At least, I couldn't
do it. And maybe it's kind of obvious, but when there is a need to
manage memory, that factor alone creates a different programmer mindset.
And in my opinion what Go does so well for a programmer is establishing
its own mindset that gives a very nice and smooth development process.
What we call "a feel of Go".

That's actually very same mistake that leads to talks like "where is my
feature X? I want feature X in your language". And the problem here is
that a language is not just a collection of features, it's a
composition of features. You can't just stick something in and make it
better (see C++) and you can't throw something out. Every feature
addition/removal affects the language as a whole, mutating it to a
different state. And in my opinion GC is a critical feature that allows
you to have memory safety and (well, let's put it that way) memory
safety is one of the major features in Go.

So.. think about it. "I want Go with templates" and "I want Go without
garbage collection" are very similar things. Both hide the desire of
improving/changing something without realization that this will affect
other areas dramatically.

And to make a summary: I tried that, I did that mistake thinking you
can build something out of Go just by taking parts you like and mixing
them in some weird way. I was stupid (to make it clear, I'm not
implying that anyone is). Hopefully what I said makes some sense.


Offtopic:

Btw. Thanks for your work on GC precision, I really hope those patches
will get into Go. One of the areas where I want to apply Go is desktop
applications. And for these you need a precise GC, because some desktop
apps have uptime measured in days or weeks (especially on geek's linux
machines) and you clearly don't want to get mozilla's firefox fame for
eating all the memory.

--
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 golan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/165ebe92-362d-44f0-9ddb-2e152276b6fc%40googlegroups.com.

--
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 golan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c03420c5-d1b0-4c73-8a61-f4fa131018f9%40googlegroups.com.

--
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/465e2109-e0a5-4fdc-9dbf-5670eb73bfef%40googlegroups.com.

-- 

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/906476454.3150.1581548180132%40wamui-sophie.atl.sa.earthlink.net.