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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6B0E7750-C1CB-4043-80BA-277D7CE08479%40ix.netcom.com.

Reply via email to