Nope. G1GC actually dates back to 2004 (see doi 10.1.1.63.6386) with Metronome even earlier (2002, I think).
Zing has actually even less throughput than the good old CMS and way more memory overhead on massively-parallel systems. However, it does guarantee realtime performance that is necessary for high-speed financial apps. Shenandoah is similar. And it's not getting better. On systems with hundreds of CPUs even small stop-the-world pauses are unacceptable, but making a pauseless compacting GC for a shared-memory system seems to be a fool's errand. By leaving out compaction, the benefits of GC become even less appealing. On Wednesday, February 12, 2020 at 2:57:04 PM UTC-8, Robert Engels wrote: > > 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.b...@gmail.com <javascript:> > 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 >>> >>> <https://groups.google.com/d/msgid/golang-nuts/165ebe92-362d-44f0-9ddb-2e152276b6fc%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 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 >> >> <https://groups.google.com/d/msgid/golang-nuts/c03420c5-d1b0-4c73-8a61-f4fa131018f9%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 golan...@googlegroups.com <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/465e2109-e0a5-4fdc-9dbf-5670eb73bfef%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/465e2109-e0a5-4fdc-9dbf-5670eb73bfef%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/36d34a8b-435d-4dab-b3b7-3d3471ff7428%40googlegroups.com.
