I found a more recent academic paper that proves my conclusions: https://www.researchgate.net/publication/326369017_From_Manual_Memory_Management_to_Garbage_Collection <https://www.researchgate.net/publication/326369017_From_Manual_Memory_Management_to_Garbage_Collection>
I am sure you can search and find many more, but the principles stated in the above are going to apply regardless. > On Feb 11, 2020, at 10:53 PM, robert engels <reng...@ix.netcom.com> wrote: > > Here is a paper from 2005 > https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf > <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.besogo...@gmail.com >> <mailto:alex.besogo...@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/ <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 golang-nuts+unsubscr...@googlegroups.com >> <mailto:golang-nuts+unsubscr...@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 golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/6B0E7750-C1CB-4043-80BA-277D7CE08479%40ix.netcom.com > > <https://groups.google.com/d/msgid/golang-nuts/6B0E7750-C1CB-4043-80BA-277D7CE08479%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/90A5BFEA-AC78-400D-96D8-D618434A7583%40ix.netcom.com.
