Your paper proves your conclusions given your assumptions :) When there is no GC runtime in a language, you are open to managing memory however you see fit, and there are lots of models which are more efficient than reference counted smart pointers or whatever. I've worked on many realtime systems in my life, and in those, we take a completely different strategy - preallocate everything, since you can't fragment memory and can't call out to sbrk() since either of those could knock you off the predictable path. When you have object pools of some kind, allocation and deallocation is stupendously fast, you modify a pointer in an array. Not allocating is a lot faster than the fastest allocator. Yes, I'm being kinda facetious here, but these papers assume that you have a programming model with a generic memory management system. Given that assumption, I can see how a GC language could be faster, but how appropriate is it when the memory footprint is fixed (such as on a game console) or when predictable performance is very important (realtime systems).
-- Marcin On Tue, Feb 11, 2020 at 9:00 PM robert engels <reng...@ix.netcom.com> wrote: > I found a more recent academic paper that proves my conclusions: > > > 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 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 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 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. > 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 > <https://groups.google.com/d/msgid/golang-nuts/90A5BFEA-AC78-400D-96D8-D618434A7583%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/CA%2Bv29LvAbrTNfCkQ77jJLYcsD37d6_8U_dUfemDiMWurcMam8w%40mail.gmail.com.
