I understand how Zing works quite well, thank you. And no, it's still horrible.
"Longer pauses in malloc" are fairy tales for children. No real allocator these days (including the slow glibc allocator) gets "fragmented". On Wednesday, February 12, 2020 at 8:18:34 PM UTC-8, robert engels wrote: > > G1GC only went into production with Java 7 in 2011. > > I don’t think you understand how Zing works. Furthermore, malloc based > systems actually have longer pauses especially as things get fragmented. > > I believe your knowledge of modern GC is way out of date. > > On Feb 12, 2020, at 8:22 PM, alex.b...@gmail.com <javascript:> wrote: > > > 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 >> 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. >> 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 golan...@googlegroups.com <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/36d34a8b-435d-4dab-b3b7-3d3471ff7428%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/36d34a8b-435d-4dab-b3b7-3d3471ff7428%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/3a15c24b-4aa5-4c2b-b0b3-f0cf5c059a49%40googlegroups.com.
