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 <javascript:> 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 <javascript:>. > 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 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.
