Re: [go-nuts] Go without garbage collector

[alex . besogonov]

I actually remember another actual example of a code that does non-trivial 
work and is written in multiple languages: 
https://github.com/ixy-languages/ixy-languages

It's pretty clear that C or Rust still easily beat any GC-based language. 
Go and C# come close because the code for the driver utilizes pooling and 
value-based programming.

On Wednesday, February 12, 2020 at 10:13:52 PM UTC-8, robert engels wrote:
>
> Also, I installed gnu gcc 9.2 and used it rather than the OSX clang, and 
> optimized C++ (-O2) time was 17.9 secs.
>
>

-- 
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/3b2e56d3-ad9b-49b3-bbb2-a4ddcbee3ee6%40googlegroups.com.

Re: [go-nuts] Go without garbage collector

[⚛]

On Thursday, February 13, 2020 at 6:59:43 AM UTC+1, robert engels wrote:
>
> Here is some pretty indisputable evidence on the advancements of GC/JVM vs 
> C++.
>
> See this paper/project https://github.com/hundt98847/multi-language-bench 
> that 
> was done by Google in 2011. If you read the paper, the C++ code was tuned 
> by expert C++ programmers at Google. The java_pro author version refused to 
> optimize further - which he felt would create “esoteric non-idomatic” Java.
>
> The paper reports that the C++ code outperformed java_pro by 4x - 12x, and 
> go_pro by 5.5x
>
> I re-ran the tests using the latest C++ compiler,Go,  and Java 13. The 
> code is unchanged since it was posted. Nothing has been modified (Go needed 
> the directory structure changed to compile). Different hardware. Different 
> OS. Different compilers. Different Java runtime. (same JVM settings - so 
> using a different default GC). All tests run on the same OS/hardware.
>
> C++ (-O2) = 16.5 secs
> C++ (-O3) = 16.5 secs
> go_pro = 19 secs
> java_pro = 8.4 secs
>
> Or Java is almost 2x faster than C++, and Go is nearly the same 
> performance as C++.
>
> Run the tests yourself… (easy to do, Makefiles included)
>
> JVM/GC has improved DRAMATICALLY in the past 9 years - static 
> compilation/optimization not so much… Stressing again - ZERO CODE CHANGES !
>
> Enjoy !
>

One can get Java performance from the C++ version by changing 3 lines of 
code: std::map -> std::unordered_map. The Java versions are using hashmaps 
as well.

java_pro: Java 8 outperforms Java 13 by about 20%.

IPC (instructions per clock) and runtime improve when the C++ code is 
compiled to target x86-32 (-m32 gcc option) instead of x86-64, 
outperforming Java 8 in elapsed time by 10%.

The Java versions are consuming 10-20 times the memory of the C++ version.

-- 
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/c970751a-aa3e-4656-876a-a5d9d9767bab%40googlegroups.com.

Re: [go-nuts] Go without garbage collector

[alex . besogonov]

The evidence is very disputable. For example, I don't know who was writing 
your paper, but they were NOT expert C++ programmers.

As an example:

> for (MaoCFG::NodeMap::iterator bb_iter = CFG_->GetBasicBlocks()->begin(); 
> bb_iter != CFG_->GetBasicBlocks()->end(); ++bb_iter) { 
> number[(*bb_iter).second] = kUnvisited; 
> }
>
>
This block is bad. The compiler will not be able to optimize it and will do 
an expensive indirect lookup on each iteration. It needs to be rewritten as:

for (MaoCFG::NodeMap::iterator bb_iter = CFG_->GetBasicBlocks()->begin(), 
bbend = CFG_->GetBasicBlocks()->end();
   bb_iter != bb_end; ++bb_iter) { 
   number[(*bb_iter).second] = kUnvisited; 
} 

The same kind of rookie mistakes (made by fresh-from college developers?) 
is all over the place. Honestly, I think that they pessimized the C++ code 
until they reached the desired outcome.

If you want a somewhat more realistic range of benchmarks, look at Debian's 
Benchmark game: 
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java.html

On Wednesday, February 12, 2020 at 9:59:43 PM UTC-8, robert engels wrote:
>
> Here is some pretty indisputable evidence on the advancements of GC/JVM vs 
> C++.
>
> See this paper/project https://github.com/hundt98847/multi-language-bench 
> that 
> was done by Google in 2011. If you read the paper, the C++ code was tuned 
> by expert C++ programmers at Google. The java_pro author version refused to 
> optimize further - which he felt would create “esoteric non-idomatic” Java.
>
> The paper reports that the C++ code outperformed java_pro by 4x - 12x, and 
> go_pro by 5.5x
>
> I re-ran the tests using the latest C++ compiler,Go,  and Java 13. The 
> code is unchanged since it was posted. Nothing has been modified (Go needed 
> the directory structure changed to compile). Different hardware. Different 
> OS. Different compilers. Different Java runtime. (same JVM settings - so 
> using a different default GC). All tests run on the same OS/hardware.
>
> C++ (-O2) = 16.5 secs
> C++ (-O3) = 16.5 secs
> go_pro = 19 secs
> java_pro = 8.4 secs
>
> Or Java is almost 2x faster than C++, and Go is nearly the same 
> performance as C++.
>
> Run the tests yourself… (easy to do, Makefiles included)
>
> JVM/GC has improved DRAMATICALLY in the past 9 years - static 
> compilation/optimization not so much… Stressing again - ZERO CODE CHANGES !
>
> Enjoy !
>
>

-- 
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/025972ea-042c-4ee9-9f11-8805e8104316%40googlegroups.com.

Re: [go-nuts] Go without garbage collector

[alex . besogonov]

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  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 

Re: [go-nuts] Go without garbage collector

[robert engels]

Also, I installed gnu gcc 9.2 and used it rather than the OSX clang, and 
optimized C++ (-O2) time was 17.9 secs.

> On Feb 12, 2020, at 11:59 PM, robert engels  wrote:
> 
> Here is some pretty indisputable evidence on the advancements of GC/JVM vs 
> C++.
> 
> See this paper/project https://github.com/hundt98847/multi-language-bench 
>  that was done by Google 
> in 2011. If you read the paper, the C++ code was tuned by expert C++ 
> programmers at Google. The java_pro author version refused to optimize 
> further - which he felt would create “esoteric non-idomatic” Java.
> 
> The paper reports that the C++ code outperformed java_pro by 4x - 12x, and 
> go_pro by 5.5x
> 
> I re-ran the tests using the latest C++ compiler,Go,  and Java 13. The code 
> is unchanged since it was posted. Nothing has been modified (Go needed the 
> directory structure changed to compile). Different hardware. Different OS. 
> Different compilers. Different Java runtime. (same JVM settings - so using a 
> different default GC). All tests run on the same OS/hardware.
> 
> C++ (-O2) = 16.5 secs
> C++ (-O3) = 16.5 secs
> go_pro = 19 secs
> java_pro = 8.4 secs
> 
> Or Java is almost 2x faster than C++, and Go is nearly the same performance 
> as C++.
> 
> Run the tests yourself… (easy to do, Makefiles included)
> 
> JVM/GC has improved DRAMATICALLY in the past 9 years - static 
> compilation/optimization not so much… Stressing again - ZERO CODE CHANGES !
> 
> Enjoy !
> 
> 
>> On Feb 12, 2020, at 10:17 PM, 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.besogo...@gmail.com 
>>>  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 

Re: [go-nuts] Go without garbage collector

[robert engels]

Here is some pretty indisputable evidence on the advancements of GC/JVM vs C++.

See this paper/project https://github.com/hundt98847/multi-language-bench 
 that was done by Google in 
2011. If you read the paper, the C++ code was tuned by expert C++ programmers 
at Google. The java_pro author version refused to optimize further - which he 
felt would create “esoteric non-idomatic” Java.

The paper reports that the C++ code outperformed java_pro by 4x - 12x, and 
go_pro by 5.5x

I re-ran the tests using the latest C++ compiler,Go,  and Java 13. The code is 
unchanged since it was posted. Nothing has been modified (Go needed the 
directory structure changed to compile). Different hardware. Different OS. 
Different compilers. Different Java runtime. (same JVM settings - so using a 
different default GC). All tests run on the same OS/hardware.

C++ (-O2) = 16.5 secs
C++ (-O3) = 16.5 secs
go_pro = 19 secs
java_pro = 8.4 secs

Or Java is almost 2x faster than C++, and Go is nearly the same performance as 
C++.

Run the tests yourself… (easy to do, Makefiles included)

JVM/GC has improved DRAMATICALLY in the past 9 years - static 
compilation/optimization not so much… Stressing again - ZERO CODE CHANGES !

Enjoy !


> On Feb 12, 2020, at 10:17 PM, 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.besogo...@gmail.com 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, 

Re: [go-nuts] Go without garbage collector

[Robert Engels]

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.besogo...@gmail.com 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 

Re: [go-nuts] Go without garbage collector

[Ian Lance Taylor]

On Wed, Feb 12, 2020 at 2:56 PM 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).
>

I just want to add a note that, as we've said before, it's not obvious that
the generational hypothesis holds for real Go code.  See the discussion by
Rick Hudson at  https://blog.golang.org/ismmkeynote.  The generational
hypothesis does seem to hold for languages like Java, and for those
languages generational GC is a win.  It's not obvious that it is a win for
Go.  So far the experimental evidence for that claim is lacking, and it's
not for lack of trying.

(Background for those who don't follow GC: the generational hypothesis is
"most objects die in the nursery", or, to put it another way, most objects
die quickly.  In Go, on the other hand, it appears that most objects live
on the stack, and thus die without being allocated or examined by the
collector.  While of course in Go some heap objects die quickly, it's not
obvious that most do, and if most objects don't die quickly then
generational GC is a lot of work for little gain.  To make things worse, in
real Go programs programmers tend to use pools (either sync.Pool or hand
rolled) for objects that die quickly, so again generational GC doesn't
help.  It's possible that if Go had generational GC people would use fewer
pools, but it's also true that for typical uses pools are likely to be more
efficient than generational GC.)

Ian

-- 
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/CAOyqgcXh1ke9giEi6bTsB51ajyb%2BcJASPB79tWEBHbYcv%2B%2B2ew%40mail.gmail.com.

[go-nuts] Looking for some nicely broken image files (gif, png, and jpeg)

['Dan Sugalski' via golang-nuts]

Specifically ones that are compatible with the Go license. The more broken 
they are the better. Bonus points for ones that trigger degenerate 
behaviour in the decoding libraries.

The tldr here is that I'm making a bunch of changes to the basic image 
libraries to add in metadata support. Since I'm in there anyway I figure I 
may as well add in some safety measures against files that consume an 
unreasonable amount of time and/or space to decode. (Or encode if anyone's 
got an image.Image that triggers bad behaviour) Having a good suite of 
known-bad files to check against will be handy to make sure the code 
actually works which is, y'know, kinda nice.

(I am aware of some bad files kicking around the web, and I've grabbed some 
for testing, but none I've run across so far have licenses on them that'd 
allow me to toss them up on github as part of the tests for this stuff. 
Hence the asking around)

-- 
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/a0555b8b-f9c9-48a0-9649-1a835b144f4a%40googlegroups.com.

Re: [go-nuts] Go without garbage collector

[alex . besogonov]

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. 

Re: [go-nuts] Go without garbage collector

[alex . besogonov]

Honestly, typical Go programs don't use that many complicated concurrent 
primitives. Typical patterns are "work fanout" and "overseer thread", both 
of which have very simple lifetime rules.

That's why a lot of typical server Go code can be ported to Rust rather 
easily.

On Wednesday, February 12, 2020 at 1:36:40 PM UTC-8, Michael Jones wrote:
>
> To me it seems the issue of concurrency and dynamic ownership of memory 
> are so deeply connected to Go’s programming methodology that the “no GC” 
> comparison is biased. 
>
> In particular, coding to do it yourself but as perfectly as the GC across 
> many concurrent routines is hard. Doing it better than the GC is hard. 
> Caution encourages use of the tuned GC. 
>
> Agree with posts above: preallocation is fastest. Hard real time from the 
> 80s lesson. 
>
> On Wed, Feb 12, 2020 at 1:07 PM > wrote:
>
>> 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 

Re: [go-nuts] Go without garbage collector

[David Riley]

> On Feb 12, 2020, at 10:10 AM, Henrik Johansson  wrote:
> 
> Well, Cassandra has a rewrite in C++ ScyllaDB hat performs many times better 
> so that particular example isn't really helping the GC case.
> 
> I don't mind the GC myself but I hear the "GC is actually faster" often and 
> it seems not to be true in the wild although I am sure theoretical cases can 
> be envisioned.

GC *can* be faster, but it depends on the workload.  I don't believe in 
universals here.

If you have a lot of random allocations, and a GC/allocator that's designed for 
that, it's great. Go works well for random-access workloads; it tends to have 
some issues with database workloads, which have more linear allocations and a 
different object lifecycle.  Check out the discussions on caching algorithms 
for dgraph for some very interesting points of view on that.

People resigned themselves to writing custom allocators for purpose-specific 
things in the game engine world in C/C++ a long time ago.  In Go, you could do 
the same for specific use cases if you wanted as well, though you'd lose the 
advantages of GC (though I'd argue that in a database, if you can't track the 
objects you own, you're in for a world of hurt anyway).

Interacting with the allocator, as well as OS-level virtual memory structures, 
has long been a facet of database and similar design in the C/C++ world, and 
it's only escapable in the higher-level language world (e.g. Go, Java) if you 
want to avoid any discussion of performance issues.  If you haven't had to 
consider structures like B-trees and B-heaps to optimize for various virtual 
memory scenarios, you haven't delved deeply enough into the problem space to be 
talking about whether GC is "better" or not, and once you have, you'll probably 
realize that there's not a simple answer to that.


- Dave


-- 
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/CEEF5C7A-D698-4F18-BB7F-F038569BEAEA%40gmail.com.

[go-nuts] Go 1.13.8 and Go 1.12.17 are released

[Alexander Rakoczy]

Hello gophers,

We have just released Go versions 1.13.8 and 1.12.17, minor point releases.

These releases include fixes to the runtime, the crypto/x509, and
net/http packages

View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.13.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.13.8" and build as usual.

Thanks to everyone who contributed to the release.

Cheers,
Alex and Carlos for the Go team

-- 
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/CAFtHmMh7MTpPayRU35uS%3DU9z2Sv2kh%3D_mxC%2BpQD515hZVO5u4Q%40mail.gmail.com.

Re: [go-nuts] Go without garbage collector

[Robert Engels]

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.besogo...@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 

Re: [go-nuts] Go without garbage collector

[⚛]

On Wednesday, February 12, 2020 at 12:55:48 AM UTC+1, deat...@gmail.com 
wrote:
>
> What about #vlang ? https://vlang.io/
>

If compile-time GC is the only memory management model that exists in V, 
then it is impossible to implement in V any program requiring 
dynamic/runtime GC such as a Python interpreter because V would free the 
memory allocated by the Python code when the Python code completes 
execution, which for some Python codes, even some trivial ones, means that 
the Python code terminates abnormally due to an out-of-memory exception.

In Go, compile-time GC could be an extra compiler switch which, when 
enabled, causes Go codes to fail to compile in case the compiler cannot 
compute how to manage memory. For real-time apps this might be a useful 
feature, although some real-time apps might still need to selectively turn 
off automatic memory deallocation to achieve their constraints.

-- 
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/8c0853ae-94b1-4a30-9180-9f17ceb04471%40googlegroups.com.

Re: [go-nuts] Go without garbage collector

[Michael Jones]

To me it seems the issue of concurrency and dynamic ownership of memory are
so deeply connected to Go’s programming methodology that the “no GC”
comparison is biased.

In particular, coding to do it yourself but as perfectly as the GC across
many concurrent routines is hard. Doing it better than the GC is hard.
Caution encourages use of the tuned GC.

Agree with posts above: preallocation is fastest. Hard real time from the
80s lesson.

On Wed, Feb 12, 2020 at 1:07 PM  wrote:

> 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 

Re: [go-nuts] Go without garbage collector

[alex . besogonov]

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 
>> 

Re: [go-nuts] Go without garbage collector

[Henrik Johansson]

Absolutely but this has been said for a very long time already and we have
still to see it.

I agree GC's are getting better and better and who knows what the future
holds.

Until then I will gladly ignore the small loss of performance simply
becausenit rarely matter for the program's I write.

On Wed, 12 Feb 2020, 19:14 Jesper Louis Andersen, <
jesper.louis.ander...@gmail.com> wrote:

> If I may make an observation here:
>
> I think the vast majority of all programs benefit in productivity from a
> GC. In the sense, that the GC is an adequate solution at the least, and a
> more efficient solution in many cases, especially if you factor in
> development time. Managing memory manually, especially in concurrent
> settings, is going to take some attention to detail, and is likely to slow
> down how fast you can get a system working.
>
> What you are likely to be looking at here is good old selection bias. The
> problems that doesn't fare well under a current generation of GCs are
> likely to bubble to the top of syndication sites, simply for the fact that
> they are interesting outliers.
>
> My experience, over the last, say 20-40 years, is that GCs are slowly
> eating more and more of the cake. As they improve, it definitely converges
> toward more viability, not less. There will always be programs for which
> they fare badly. But as they are detected, so are GCs improved.
>
> On Wed, Feb 12, 2020 at 4:11 PM Henrik Johansson 
> wrote:
>
>> Well, Cassandra has a rewrite in C++ ScyllaDB hat performs many times
>> better so that particular example isn't really helping the GC case.
>>
>> I don't mind the GC myself but I hear the "GC is actually faster" often
>> and it seems not to be true in the wild although I am sure theoretical
>> cases can be envisioned.
>>
>> On Wed, 12 Feb 2020, 16:06 Kevin Chadwick,  wrote:
>>
>>> On 2020-02-12 14:02, Robert Engels wrote:
>>> > Most of that is because their codebase predates Java. There are more
>>> modern dbs
>>> > like Cassandra that are in Java. Certainly Hadoop is probably the
>>> largest
>>> > distributed database in the world and it’s written in Java.
>>>
>>> Bound to use more cpu cycles and memory than a c equivalent. Of course
>>> postgres
>>> is more capable.
>>>
>>>
>>> https://blog.timescale.com/blog/time-series-data-cassandra-vs-timescaledb-postgresql-7c2cc50a89ce/
>>>
>>> --
>>> 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/f388606c-7f52-78bc-f59c-776688114e4f%40gmail.com
>>> .
>>>
>> --
>> 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/CAKOF695amjn_FvHrh1S2x41knXOQ9Dq-yX2%2Bfh5jDL_dDJenaA%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> J.
>

-- 
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/CAKOF6944bsaL%2Bfj4LBKapEk4O_cr5rs2wzBT%3DCsR1uBEZnxCsw%40mail.gmail.com.

Re: [go-nuts] Go without garbage collector

[Robert Engels]

Very well said.-Original Message-
From: Jesper Louis Andersen 
Sent: Feb 12, 2020 12:13 PM
To: Henrik Johansson 
Cc: Kevin Chadwick , golang-nuts 
Subject: Re: [go-nuts] Go without garbage collector

If I may make an observation here:I think the vast majority of all programs benefit in productivity from a GC. In the sense, that the GC is an adequate solution at the least, and a more efficient solution in many cases, especially if you factor in development time. Managing memory manually, especially in concurrent settings, is going to take some attention to detail, and is likely to slow down how fast you can get a system working.What you are likely to be looking at here is good old selection bias. The problems that doesn't fare well under a current generation of GCs are likely to bubble to the top of syndication sites, simply for the fact that they are interesting outliers.My experience, over the last, say 20-40 years, is that GCs are slowly eating more and more of the cake. As they improve, it definitely converges toward more viability, not less. There will always be programs for which they fare badly. But as they are detected, so are GCs improved.On Wed, Feb 12, 2020 at 4:11 PM Henrik Johansson  wrote:Well, Cassandra has a rewrite in C++ ScyllaDB hat performs many times better so that particular example isn't really helping the GC case.I don't mind the GC myself but I hear the "GC is actually faster" often and it seems not to be true in the wild although I am sure theoretical cases can be envisioned.On Wed, 12 Feb 2020, 16:06 Kevin Chadwick,  wrote:On 2020-02-12 14:02, Robert Engels wrote:
> Most of that is because their codebase predates Java. There are more modern dbs
> like Cassandra that are in Java. Certainly Hadoop is probably the largest
> distributed database in the world and it’s written in Java.

Bound to use more cpu cycles and memory than a c equivalent. Of course postgres
is more capable.

https://blog.timescale.com/blog/time-series-data-cassandra-vs-timescaledb-postgresql-7c2cc50a89ce/

-- 
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/f388606c-7f52-78bc-f59c-776688114e4f%40gmail.com.




-- 
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/CAKOF695amjn_FvHrh1S2x41knXOQ9Dq-yX2%2Bfh5jDL_dDJenaA%40mail.gmail.com.
-- J.



-- 
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/CAGrdgiWTDKpdX3tMAecRf770YWDsFHbvjY%2BTcMAxQ5A3LZMe6w%40mail.gmail.com.




-- 
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/1271509650.1882.1581532299493%40wamui-sophie.atl.sa.earthlink.net.

Re: [go-nuts] Go without garbage collector

[Jesper Louis Andersen]

If I may make an observation here:

I think the vast majority of all programs benefit in productivity from a
GC. In the sense, that the GC is an adequate solution at the least, and a
more efficient solution in many cases, especially if you factor in
development time. Managing memory manually, especially in concurrent
settings, is going to take some attention to detail, and is likely to slow
down how fast you can get a system working.

What you are likely to be looking at here is good old selection bias. The
problems that doesn't fare well under a current generation of GCs are
likely to bubble to the top of syndication sites, simply for the fact that
they are interesting outliers.

My experience, over the last, say 20-40 years, is that GCs are slowly
eating more and more of the cake. As they improve, it definitely converges
toward more viability, not less. There will always be programs for which
they fare badly. But as they are detected, so are GCs improved.

On Wed, Feb 12, 2020 at 4:11 PM Henrik Johansson 
wrote:

> Well, Cassandra has a rewrite in C++ ScyllaDB hat performs many times
> better so that particular example isn't really helping the GC case.
>
> I don't mind the GC myself but I hear the "GC is actually faster" often
> and it seems not to be true in the wild although I am sure theoretical
> cases can be envisioned.
>
> On Wed, 12 Feb 2020, 16:06 Kevin Chadwick,  wrote:
>
>> On 2020-02-12 14:02, Robert Engels wrote:
>> > Most of that is because their codebase predates Java. There are more
>> modern dbs
>> > like Cassandra that are in Java. Certainly Hadoop is probably the
>> largest
>> > distributed database in the world and it’s written in Java.
>>
>> Bound to use more cpu cycles and memory than a c equivalent. Of course
>> postgres
>> is more capable.
>>
>>
>> https://blog.timescale.com/blog/time-series-data-cassandra-vs-timescaledb-postgresql-7c2cc50a89ce/
>>
>> --
>> 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/f388606c-7f52-78bc-f59c-776688114e4f%40gmail.com
>> .
>>
> --
> 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/CAKOF695amjn_FvHrh1S2x41knXOQ9Dq-yX2%2Bfh5jDL_dDJenaA%40mail.gmail.com
> 
> .
>


-- 
J.

-- 
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/CAGrdgiWTDKpdX3tMAecRf770YWDsFHbvjY%2BTcMAxQ5A3LZMe6w%40mail.gmail.com.

Re: [go-nuts] Go without garbage collector

[Robert Engels]

Most embedded systems are highly modular with limited inputs and outputs. It is 
far easier to apply custom memory handling to the module. 

It’s is the larger controller application that is far more complex as it has to 
deal with all of the inputs BBC and outputs of every module. It is very hard to 
write these systems - that often include elaborate UIs in a fixed memory 
environment. 

The point being lost is that if you don’t do any dynamic memory handling you 
can turn off GC - then you are strictly comparing compiler efficiencies and 
again a dynamic JVM can out perform statically compiled apps - but that’s 
another discussion. 

> On Feb 12, 2020, at 11:50 AM, Marcin Romaszewicz  wrote:
> 
> 
> 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  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  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 

Re: [go-nuts] Go without garbage collector

[Marcin Romaszewicz]

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  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  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
>>> 

Re: [go-nuts] Go without garbage collector

[Henrik Johansson]

It's beside the point and you are wrong but please rerun in any setup you
want.

Anyway for "day job" I am fine with GC.

On Wed, 12 Feb 2020, 18:05 Robert Engels,  wrote:

> Note sure where you are getting that - their own report
> https://www.scylladb.com/product/benchmarks/aws-i3-metal-benchmark/ is
> garbage as their rational is completely flawed in choosing less bare metal
> nodes (but far bigger) - they have exponentially reduced the communication
> costs... Additionally, running single Java nodes on the metal machine would
> perform far better. Also, the GC tuning is not designed for latency with
> max pauses of 500ms.
>
> Re-run the tests on Shenandoah or Zing and see how they compare.
>
> -Original Message-
> From: Henrik Johansson
> Sent: Feb 12, 2020 9:10 AM
> To: Kevin Chadwick
> Cc: golang-nuts
> Subject: Re: [go-nuts] Go without garbage collector
>
> Well, Cassandra has a rewrite in C++ ScyllaDB hat performs many times
> better so that particular example isn't really helping the GC case.
>
> I don't mind the GC myself but I hear the "GC is actually faster" often
> and it seems not to be true in the wild although I am sure theoretical
> cases can be envisioned.
>
> On Wed, 12 Feb 2020, 16:06 Kevin Chadwick,  wrote:
>
>> On 2020-02-12 14:02, Robert Engels wrote:
>> > Most of that is because their codebase predates Java. There are more
>> modern dbs
>> > like Cassandra that are in Java. Certainly Hadoop is probably the
>> largest
>> > distributed database in the world and it’s written in Java.
>>
>> Bound to use more cpu cycles and memory than a c equivalent. Of course
>> postgres
>> is more capable.
>>
>>
>> https://blog.timescale.com/blog/time-series-data-cassandra-vs-timescaledb-postgresql-7c2cc50a89ce/
>>
>> --
>> 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/f388606c-7f52-78bc-f59c-776688114e4f%40gmail.com
>> .
>>
> --
> 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/CAKOF695amjn_FvHrh1S2x41knXOQ9Dq-yX2%2Bfh5jDL_dDJenaA%40mail.gmail.com
> 
> .
>
>
>
>
>

-- 
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/CAKOF694QKE4Ha9mRf7eRCq9PiB5WEtrCYBgcSrAmF-RmaXL0_g%40mail.gmail.com.

Re: [go-nuts] Go without garbage collector

[Robert Engels]

Note sure where you are getting that - their own report  https://www.scylladb.com/product/benchmarks/aws-i3-metal-benchmark/ is garbage as their rational is completely flawed in choosing less bare metal nodes (but far bigger) - they have exponentially reduced the communication costs... Additionally, running single Java nodes on the metal machine would perform far better. Also, the GC tuning is not designed for latency with max pauses of 500ms.Re-run the tests on Shenandoah or Zing and see how they compare.-Original Message-
From: Henrik Johansson 
Sent: Feb 12, 2020 9:10 AM
To: Kevin Chadwick 
Cc: golang-nuts 
Subject: Re: [go-nuts] Go without garbage collector

Well, Cassandra has a rewrite in C++ ScyllaDB hat performs many times better so that particular example isn't really helping the GC case.I don't mind the GC myself but I hear the "GC is actually faster" often and it seems not to be true in the wild although I am sure theoretical cases can be envisioned.On Wed, 12 Feb 2020, 16:06 Kevin Chadwick,  wrote:On 2020-02-12 14:02, Robert Engels wrote:
> Most of that is because their codebase predates Java. There are more modern dbs
> like Cassandra that are in Java. Certainly Hadoop is probably the largest
> distributed database in the world and it’s written in Java.

Bound to use more cpu cycles and memory than a c equivalent. Of course postgres
is more capable.

https://blog.timescale.com/blog/time-series-data-cassandra-vs-timescaledb-postgresql-7c2cc50a89ce/

-- 
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/f388606c-7f52-78bc-f59c-776688114e4f%40gmail.com.




-- 
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/CAKOF695amjn_FvHrh1S2x41knXOQ9Dq-yX2%2Bfh5jDL_dDJenaA%40mail.gmail.com.




-- 
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/977082079.1276.1581527152975%40wamui-sophie.atl.sa.earthlink.net.

Re: [go-nuts] Re: Checking if two map variables refer to the same map

[Jake Montgomery]

The playground is your friend: https://play.golang.org/p/p10XugRD4_z
So, the answer is no.

On Tuesday, February 11, 2020 at 6:56:05 PM UTC-5, Kevin Regan wrote:
>
> Would something like this work:
>
> m1 := make(map[string]string)
> m2 := m1
>
> if  ==  {
>...
> }
>
>
> On Tue, Feb 11, 2020 at 5:50 AM roger peppe  > wrote:
>
>> I believe that the main reason that equality isn't defined on maps (and 
>> slices) is to preserve the future possibility that equality might work at a 
>> whole-value level rather than on a reference level. I suspect that one of 
>> these days a final decision will be made...
>>
>>
>> On Mon, 10 Feb 2020 at 23:42, 'Kevin Regan' via golang-nuts <
>> golan...@googlegroups.com > wrote:
>>
>>> I just ran into this... ...makes me like go a little less.
>>>
>>>
>>> On Tuesday, August 7, 2018 at 6:34:03 AM UTC-7 mi...@daglabs.com wrote:
>>>
 Sorry for bumping a very old thread, but I absolutely disagree with the 
 people stating that this problem is contrived, and I got here from a 
 Google 
 search, so this might be relevant for some people.

 A very real use-case for reference-comparing maps is when testing 
 .Clone() methods. You want to make sure that the clone is an actual clone, 
 and that all the properties of the cloned object are also a clone, etc. In 
 these cases you want to reference-compare everything.

 That said, reflect.ValueOf(xxx).Pointer is more than sufficient for 
 this use-case.


 On Monday, July 15, 2013 at 3:50:01 AM UTC+3, Yi DENG wrote:
>
> There're always something that is not comparable. You can consider map 
> as one of this. If you have to check, use the pointer form.
>
> David
>
> On Saturday, July 13, 2013 7:35:55 PM UTC+8, Jsor wrote:
>>
>> I ask for maps because for slices this seems potentially problematic: 
>> what does "same reference" entail for a slice? Overlapping underlying 
>> arrays? Same starting pointer regardless of whether their len matches? 
>> Same 
>> start, end, len, and cap? And so on. Though I guess "reference-equality" 
>> would be pretty well defined for channels.
>>
>> However, for maps determining "sameness" at a reference level seems 
>> like a much more well defined question, and a much simpler one to 
>> answer. 
>> Yet I can't figure out a good way to do it. Perhaps with 
>> reflect.Value.UnsafePointer (would that even work)? Either way, that 
>> seems 
>> like overcomplicating things. The "easiest" way to do it seems to be 
>> something like this, dreamt up on the go-nuts IRC when I asked this: 
>> http://play.golang.org/p/6Ffxfx7zBb
>>
>> But I think we can all agree that that's a rather silly and limited 
>> solution (and to be fair wasn't suggested in earnest).
>>
>> I can see why == isn't defined on maps, too many people would likely 
>> mistake it for a deep equality test (if that was indeed the reason), but 
>> it 
>> seems like there should be some semi-trivial way to see if two map 
>> variables refer to the same map. Perhaps a need just wasn't seen for 
>> such 
>> an operation? Maybe it's really a more difficult/expensive test than I 
>> assumed?
>>
> -- 
>>> 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/a1f4e265-4523-41be-a67a-f43610fd430a%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
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/144109a8-c0d7-42f3-a1cc-1e642d60b533%40googlegroups.com.

Re: [go-nuts] Go without garbage collector

[Henrik Johansson]

Well, Cassandra has a rewrite in C++ ScyllaDB hat performs many times
better so that particular example isn't really helping the GC case.

I don't mind the GC myself but I hear the "GC is actually faster" often and
it seems not to be true in the wild although I am sure theoretical cases
can be envisioned.

On Wed, 12 Feb 2020, 16:06 Kevin Chadwick,  wrote:

> On 2020-02-12 14:02, Robert Engels wrote:
> > Most of that is because their codebase predates Java. There are more
> modern dbs
> > like Cassandra that are in Java. Certainly Hadoop is probably the largest
> > distributed database in the world and it’s written in Java.
>
> Bound to use more cpu cycles and memory than a c equivalent. Of course
> postgres
> is more capable.
>
>
> https://blog.timescale.com/blog/time-series-data-cassandra-vs-timescaledb-postgresql-7c2cc50a89ce/
>
> --
> 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/f388606c-7f52-78bc-f59c-776688114e4f%40gmail.com
> .
>

-- 
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/CAKOF695amjn_FvHrh1S2x41knXOQ9Dq-yX2%2Bfh5jDL_dDJenaA%40mail.gmail.com.

Re: [go-nuts] Go without garbage collector

[Kevin Chadwick]

On 2020-02-12 14:02, Robert Engels wrote:
> Most of that is because their codebase predates Java. There are more modern 
> dbs
> like Cassandra that are in Java. Certainly Hadoop is probably the largest
> distributed database in the world and it’s written in Java.

Bound to use more cpu cycles and memory than a c equivalent. Of course postgres
is more capable.

https://blog.timescale.com/blog/time-series-data-cassandra-vs-timescaledb-postgresql-7c2cc50a89ce/

-- 
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/f388606c-7f52-78bc-f59c-776688114e4f%40gmail.com.

Re: [go-nuts] Go without garbage collector

[Kevin Chadwick]

On 2020-02-12 13:23, Henrik Johansson wrote:
> We shouldn't pretend that GC is be all end all to both developer and runtime
> performance.

Frankly I think performance has a lot to answer for and likely why a secure C
that drops features and/or performance, has never become mainstream. A default
of slow with unsafe like go has would be nice in the embedded world. After all
hw acceleration or assembly often replaces C where performance is required.

As far as GO is concerned, for it's intended use cases. OOM avoidance rather
than performance is the concern, if anything. You can always throw more hardware
at performance and it already performs many times faster than python etc..

-- 
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/ae75de21-abaf-919d-e100-68b9d6135cc6%40gmail.com.

Re: [go-nuts] Go without garbage collector

[Robert Engels]

Most of that is because their codebase predates Java. There are more modern dbs 
like Cassandra that are in Java. Certainly Hadoop is probably the largest 
distributed database in the world and it’s written in Java. 

> On Feb 12, 2020, at 7:24 AM, Henrik Johansson  wrote:
> 
> 
> Sure, writing these system in a non-GC language is harder but that's not 
> really what is talked about here right?
> There is a reason why databases are not really successful in Java for 
> example. Caching software are predominantly in C/C++.
> Beating highly tuned C/C++ is not something that a GC can do by itself. What 
> it brings is convenience and frankly it's "good enough"
> for most cases. We shouldn't pretend that GC is be all end all to both 
> developer and runtime performance.
> 
>> On Wed, Feb 12, 2020 at 2:10 PM Robert Engels  wrote:
>> Aren’t we all all “students” :) 
>> 
>> The conclusions you cite are from the 2005 paper. 
>> 
>> I’m sure I can find other more recent peer reviewed papers that draw the 
>> same conclusions as the “student” one. 
>> 
>> I don’t think it is necessary though. If you understand how malloc or 
>> tcmalloc and how modern GC works you’ll also know why it’s the case. Even 
>> with tcmalloc, highly concurrent dynamic memory systems are a problem 
>> without GC. A simple example, with Rust dealloc a large dynamic object graph 
>> vs a GC language- expensive vs cheap. 
>> 
 On Feb 12, 2020, at 6:36 AM, Brian Candler  wrote:
 
>>> 
 On Wednesday, 12 February 2020 05:00:41 UTC, robert engels 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
 
>>> 
>>> It's a student paper.
>>> 
>>> The bit that caught my eye was results of simulation using real Java 
>>> programs:
>>> 
>>> it’s been proven that the runtime performance of the best-performing 
>>> garbage collector is competitive with explicit memory management when given 
>>> enough memory. In particular, when garbage collection has five times as much 
>>> memory as required, its runtime performance matches or slightly exceeds 
>>> that of explicit memory management.
>>> 
>>> However, garbage collection’s performance degrades substantially when it 
>>> must use smaller heaps. With three times as much memory, it runs 17% slower 
>>> on average, and with twice as much memory, it runs 70% slower.
>>> 
>>> -- 
>>> 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/230ed453-0897-48a7-8662-4807e7774e85%40googlegroups.com.
>> 
>> -- 
>> 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/EF2B49E6-2A39-4582-9308-84F5D35F91EA%40ix.netcom.com.

-- 
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/8E1BA446-CEC6-4A39-B8B4-73B69265EDD0%40ix.netcom.com.

Re: [go-nuts] Virus detection issues on Windows/386 binaries built with -ldflags -s -w

[Ian Lance Taylor]

On Tue, Feb 11, 2020 at 9:06 PM ajstarks  wrote:
>
> VT detected issues.  As mentioned these are false positives:
>
> https://www.virustotal.com/gui/file/77cbc92defdabf7e308849f0dd5e784010d9b4548b99b50df52533b949a14d85/detection

FYI:  https://golang.org/doc/faq#virus

Ian


> On Tuesday, February 11, 2020 at 11:50:37 PM UTC-5, ajstarks wrote:
>>
>> A bit more info: building natively on Windows 10, the detection is NOT 
>> triggered.
>> I will submit the offending file.
>>
>> On Tuesday, February 11, 2020 at 11:30:48 PM UTC-5, andrey mirtchovski wrote:
>>>
>>> you can find similar detections on virustotal. unfortunately it looks
>>> like a false positive:
>>>
>>> https://www.virustotal.com/gui/file/93eb448cedd4b4355065a4f9193d8548b02bc56ed5ba9e774095f9ab3da46227/detection
>>>
>>> there are members of this community working for microsoft, perhaps
>>> they'll have an avenue that will allow their engine to avoid a false
>>> positive on go code. not sure if they have an open channel to address
>>> this.
>>>
>>> On Tue, Feb 11, 2020 at 9:15 PM ajstarks  wrote:
>>> >
>>> > When building Windows binaries for pdfdeck [1] 
>>> > (https://github.com/ajstarks/deck/tree/master/cmd/pdfdeck) I noticed that 
>>> > the binary generated with on linux with:
>>> >
>>> > GOOS=windows GOARCH=386 go build -ldflags="-s -w" -o 
>>> > windows-386-pdfdeck.exe github.com/ajstarks/deck/cmd/pdfdeck
>>> >
>>> > will cause the Windows 10 Defender virus detection to think the binary is 
>>> > infected with Trojan:Win32/Wacatac.C!ml
>>> >
>>> > simply removing the -ldflags builds a binary that runs with no issues.  
>>> > Has anyone else seen this?
>>> >
>>> > --
>>> > 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/67837c19-9d19-4976-8b12-44a7b8fedf6d%40googlegroups.com.
>
> --
> 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/4b7c752b-6b82-4ec9-8d66-3ad9d663368a%40googlegroups.com.

-- 
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/CAOyqgcVRJ3W8hwKThJJEybzM4BLE77P8Xeg3Dkcb6z4GVL2a0w%40mail.gmail.com.

Re: [go-nuts] Compilation of CGO project

[Ian Lance Taylor]

On Wed, Feb 12, 2020 at 12:44 AM Nitish Saboo  wrote:
>
> I have A CGO project.While compiling the project I am getting the following 
> error:
>
> In file included from 
> lib/../deps/syslog/syslog-ng-3.25.1/lib/logmsg/logmsg.h:31:0,
> [07:38:51][shellscript]  from lib/syslog-node.c:9:
> [07:38:51][shellscript] 
> lib/../deps/syslog/syslog-ng-3.25.1/install/include/syslog-ng/serialize.h: In 
> function 'serialize_read_uint32_array':
> [07:38:51][shellscript] 
> lib/../deps/syslog/syslog-ng-3.25.1/install/include/syslog-ng/serialize.h:120:7:
>  error: 'for' loop initial declarations are only allowed in C99 mode
> [07:38:51][shellscript]for (int i = 0; i < elements; i++)
> [07:38:51][shellscript]^
> [07:38:51][shellscript] 
> lib/../deps/syslog/syslog-ng-3.25.1/install/include/syslog-ng/serialize.h:120:7:
>  note: use option -std=c99 or -std=gnu99 to compile your code
> [07:38:51][shellscript] 
> lib/../deps/syslog/syslog-ng-3.25.1/install/include/syslog-ng/serialize.h: In 
> function 'serialize_read_uint16_array':
> [07:38:51][shellscript] 
> lib/../deps/syslog/syslog-ng-3.25.1/install/include/syslog-ng/serialize.h:134:7:
>  error: 'for' loop initial declarations are only allowed in C99 mode
> [07:38:51][shellscript]for (int i = 0; i < elements; i++)
>
>
> I am passing these flags for compilation of CGO project:
>
> //#cgo CFLAGS: -I${SRCDIR}/../deps/syslog/syslog-ng-3.6.2/
> //#cgo CFLAGS: -I${SRCDIR}/../deps/syslog/syslog-ng-3.6.2/build
> //#cgo CFLAGS: -I${SRCDIR}/../deps/syslog/syslog-ng-3.6.2/install/include/
> //#cgo CFLAGS: 
> -I${SRCDIR}/../deps/syslog/syslog-ng-3.6.2/install/include/syslog-ng
> //#cgo LDFLAGS: -L${SRCDIR}/../deps/syslog/syslog-ng-3.6.2/install/lib 
> -lsyslog-ng
> //#cgo LDFLAGS: 
> -L${SRCDIR}/../deps/syslog/syslog-ng-3.6.2/install/lib/syslog-ng -ldbparser
> //#cgo pkg-config: eventlog
> //#cgo CFLAGS: -I/usr/include/glib-2.0
> //#cgo CFLAGS: -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
>
> Currently the C code is getting compiled against gcc -std=gnu99.Looks like I 
> have to compile the C code against  gcc -std=C99.
> How can I pass this flag from Go code so that the C code gets compiled 
> against -std=C99.

Try

//#cgo CFLAGS: -std=c99

Ian

-- 
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/CAOyqgcU91mZY%2BsRS4KxDJGLWK6vBe1Z%2BsXPrxFuiPW0fJ0FoZw%40mail.gmail.com.

Re: [go-nuts] Go without garbage collector

[Henrik Johansson]

Sure, writing these system in a non-GC language is harder but that's not
really what is talked about here right?
There is a reason why databases are not really successful in Java for
example. Caching software are predominantly in C/C++.
Beating highly tuned C/C++ is not something that a GC can do by itself.
What it brings is convenience and frankly it's "good enough"
for most cases. We shouldn't pretend that GC is be all end all to both
developer and runtime performance.

On Wed, Feb 12, 2020 at 2:10 PM Robert Engels  wrote:

> Aren’t we all all “students” :)
>
> The conclusions you cite are from the 2005 paper.
>
> I’m sure I can find other more recent peer reviewed papers that draw the
> same conclusions as the “student” one.
>
> I don’t think it is necessary though. If you understand how malloc or
> tcmalloc and how modern GC works you’ll also know why it’s the case. Even
> with tcmalloc, highly concurrent dynamic memory systems are a problem
> without GC. A simple example, with Rust dealloc a large dynamic object
> graph vs a GC language- expensive vs cheap.
>
> On Feb 12, 2020, at 6:36 AM, Brian Candler  wrote:
>
> 
> On Wednesday, 12 February 2020 05:00:41 UTC, robert engels 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
>>
>>
> It's a student paper.
>
> The bit that caught my eye was results of simulation using real Java
> programs:
>
> *it’s been proven that the runtime performance of the best-performing
> garbage collector is competitive with explicit memory management when given
> enough memory. In particular, when garbage collection has five times as much
> memory as required, its runtime performance matches or slightly exceeds
> that of explicit memory management.*
>
>
> *However, garbage collection’s performance degrades substantially when it
> must use smaller heaps. With three times as much memory, it runs 17% slower
> on average, and with twice as much memory, it runs 70% slower.*
>
> --
> 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/230ed453-0897-48a7-8662-4807e7774e85%40googlegroups.com
> 
> .
>
> --
> 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/EF2B49E6-2A39-4582-9308-84F5D35F91EA%40ix.netcom.com
> 
> .
>

-- 
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/CAKOF697R-VmPxbjuP8%2BkFkO5J2M9JVKjK44qNX_Qb1AczZAHcA%40mail.gmail.com.

Re: [go-nuts] Go without garbage collector

[Robert Engels]

Aren’t we all all “students” :) 

The conclusions you cite are from the 2005 paper. 

I’m sure I can find other more recent peer reviewed papers that draw the same 
conclusions as the “student” one. 

I don’t think it is necessary though. If you understand how malloc or tcmalloc 
and how modern GC works you’ll also know why it’s the case. Even with tcmalloc, 
highly concurrent dynamic memory systems are a problem without GC. A simple 
example, with Rust dealloc a large dynamic object graph vs a GC language- 
expensive vs cheap. 

> On Feb 12, 2020, at 6:36 AM, Brian Candler  wrote:
> 
> 
>> On Wednesday, 12 February 2020 05:00:41 UTC, robert engels 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
>> 
> 
> It's a student paper.
> 
> The bit that caught my eye was results of simulation using real Java programs:
> 
> it’s been proven that the runtime performance of the best-performing garbage 
> collector is competitive with explicit memory management when given enough 
> memory. In particular, when garbage collection has five times as much memory 
> as required, its runtime performance matches or slightly exceeds that of 
> explicit memory management.
> 
> However, garbage collection’s performance degrades substantially when it must 
> use smaller heaps. With three times as much memory, it runs 17% slower on 
> average, and with twice as much memory, it runs 70% slower.
> 
> -- 
> 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/230ed453-0897-48a7-8662-4807e7774e85%40googlegroups.com.

-- 
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/EF2B49E6-2A39-4582-9308-84F5D35F91EA%40ix.netcom.com.

Re: [go-nuts] Go without garbage collector

[Brian Candler]

On Tuesday, 11 February 2020 23:55:48 UTC, deat...@gmail.com wrote:
>
> What about #vlang ? https://vlang.io/
>
>
https://vlang.io/docs#memory

"(Work in progress) There's no garbage collection or reference counting. V 
cleans everything up during compilation. If your V program compiles, it's 
guaranteed that it's going to be leak free."

I don't think they've understood the problem at all. There is no indication 
of how they plan to deal with this.  Real-world programs allocate 
long-lived stuff on the heap.  If there is no GC, I believe they will end 
up re-inventing Rust's ownership/borrowing paradigm.

-- 
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/da280376-cf0d-4cb1-bbfe-0c3d171ffb06%40googlegroups.com.

Re: [go-nuts] Go without garbage collector

[Brian Candler]

On Wednesday, 12 February 2020 05:00:41 UTC, robert engels 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
>
>
It's a student paper.

The bit that caught my eye was results of simulation using real Java 
programs:

*it’s been proven that the runtime performance of the best-performing 
garbage collector is competitive with explicit memory management when given 
enough memory. In particular, when garbage collection has five times as much 
memory as required, its runtime performance matches or slightly exceeds 
that of explicit memory management.*


*However, garbage collection’s performance degrades substantially when it 
must use smaller heaps. With three times as much memory, it runs 17% slower 
on average, and with twice as much memory, it runs 70% slower.*

-- 
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/230ed453-0897-48a7-8662-4807e7774e85%40googlegroups.com.

Re: [go-nuts] Go without garbage collector

[Kevin Chadwick]

On 2020-02-12 04:53, robert engels wrote:
> You can write robust systems without dynamic memory, but it is very very
> difficult - beyond the skills of most developers.

Interestingly, Global variables are often frouned upon and quite rightly on
computer systems (I include rpi/phones), despite being widely used in simpler
embedded applications. Yet Greenhills software (ghs.com) have a military
embedded OS that costs a fortune and who's marketing states it *ONLY* uses
global variables for guaranteed reliability. I am sure it's development caused a
heck of a lot of head scratching and perhaps it has 0 concurrency. In my mind,
controlled stack memory is still a must for sanity. Of course without
concurrency, judging dynamic memory use, isn't a difficult task anyway. It's a
lot easier to estimate stack usage though with buffer insurance.

-- 
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/a74e0dd4-b8b6-f0a9-87bc-233e97e3d48b%40gmail.com.

[go-nuts] Re: arm64 builder on raspberry pi 3B/3B+

[Liam]

The archlinuxarm.org project has great support for a variety of arm64 
boards.


On Tuesday, February 11, 2020 at 7:33:04 PM UTC-8, kortschak wrote:
>
> I have been wanting an arm64 builder to do local testing for Gonum 
> recently. Unfortunately, though RPi 3 and 4 have 64 bit cores, Raspbian 
> is 32 bit, so they don't satisfy. 
>
> However, I found this article[1] which goes through installing a UEFI 
> bootloader and vanilla Debian Buster install on 3B/3B+. 
>
> I tried it out yesterday and it worked perfectly (making sure to follow 
> the instructions to the letter). 
>
> There is also a UEFI bootloader setup for the RPi4[2], but it is 
> currently experimental. 
>
> Dan 
>
> [1]
> https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.html 
> [2]https://github.com/pftf/RPi4 
>
>
>

-- 
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/a791b76b-9027-4a32-a744-dde89ffed242%40googlegroups.com.

[go-nuts] Compilation of CGO project

[Nitish Saboo]

Hi ,

I have A CGO project.While compiling the project I am getting the following
error:

In file included from
lib/../deps/syslog/syslog-ng-3.25.1/lib/logmsg/logmsg.h:31:0,
[07:38:51][shellscript]  from lib/syslog-node.c:9:
[07:38:51][shellscript]
lib/../deps/syslog/syslog-ng-3.25.1/install/include/syslog-ng/serialize.h:
In function 'serialize_read_uint32_array':
[07:38:51][shellscript]
lib/../deps/syslog/syslog-ng-3.25.1/install/include/syslog-ng/serialize.h:120:7:
error: 'for' loop initial declarations are only allowed in C99 mode
[07:38:51][shellscript]for (int i = 0; i < elements; i++)
[07:38:51][shellscript]^
[07:38:51][shellscript]
lib/../deps/syslog/syslog-ng-3.25.1/install/include/syslog-ng/serialize.h:120:7:
note: use option -std=c99 or -std=gnu99 to compile your code
[07:38:51][shellscript]
lib/../deps/syslog/syslog-ng-3.25.1/install/include/syslog-ng/serialize.h:
In function 'serialize_read_uint16_array':
[07:38:51][shellscript]
lib/../deps/syslog/syslog-ng-3.25.1/install/include/syslog-ng/serialize.h:134:7:
error: 'for' loop initial declarations are only allowed in C99 mode
[07:38:51][shellscript]for (int i = 0; i < elements; i++)


I am passing these flags for compilation of CGO project:

//#cgo CFLAGS: -I${SRCDIR}/../deps/syslog/syslog-ng-3.6.2/
//#cgo CFLAGS: -I${SRCDIR}/../deps/syslog/syslog-ng-3.6.2/build
//#cgo CFLAGS: -I${SRCDIR}/../deps/syslog/syslog-ng-3.6.2/install/include/
//#cgo CFLAGS:
-I${SRCDIR}/../deps/syslog/syslog-ng-3.6.2/install/include/syslog-ng
//#cgo LDFLAGS: -L${SRCDIR}/../deps/syslog/syslog-ng-3.6.2/install/lib
-lsyslog-ng
//#cgo LDFLAGS:
-L${SRCDIR}/../deps/syslog/syslog-ng-3.6.2/install/lib/syslog-ng -ldbparser
//#cgo pkg-config: eventlog
//#cgo CFLAGS: -I/usr/include/glib-2.0
//#cgo CFLAGS: -I/usr/lib/x86_64-linux-gnu/glib-2.0/include

Currently the C code is getting compiled against gcc -std=gnu99.Looks like
I have to compile the C code against  gcc -std=C99.
How can I pass this flag from Go code so that the C code gets compiled
against -std=C99.

Thanks,
Nitish

-- 
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/CALjMrq6KUXUXJW3PZedzx_pwTet7%2B3ecjm57dzzDK8bdY8Jtkg%40mail.gmail.com.

Re: [go-nuts] Re: arm64 builder on raspberry pi 3B/3B+

[Dan Kortschak]

The builder is for running tests on GOARCH=arm64. I have previously run
tests using qemu-arm, but this is currently broken (and is slow even
when not broken).

On Wed, 2020-02-12 at 00:15 -0800, Brian Candler wrote:
> Interesting to know.
> 
> When you say "an arm64 builder", I presume you already know that go
> can cross-compile any architecture on any machine (using
> GOOS/GOARCH).
> 
> For testing, did you consider emulating an arm64 with qemu - or is
> that too slow / insufficiently realistic?
> https://gist.github.com/stefanozanella/4608873
> 


-- 
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/b43de34ef5da544d3ce47bbfd9057d480c1a91c1.camel%40kortschak.io.

[go-nuts] Re: arm64 builder on raspberry pi 3B/3B+

[Brian Candler]

Interesting to know.

When you say "an arm64 builder", I presume you already know that go can 
cross-compile 

 any 
architecture on any machine (using GOOS/GOARCH).

For testing, did you consider emulating an arm64 with qemu - or is that too 
slow / insufficiently realistic?
https://gist.github.com/stefanozanella/4608873

-- 
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/5ae605ae-cb6f-40c9-9b44-10e09da18d2a%40googlegroups.com.