Re: [go-nuts] Go without garbage collector

[Robert Engels]

Reference counting is GC (at least if you are using automatic reference counting, which is what all of cited systems do). It was one of the earliest forms of GC as it is the easiest to implement.

That Java code does not represent the C++ code. The C++ code is in no way concurrent. The suggested Java code creates all sorts of "happens before" semantics that are not in any of the language versions.

Clearly my advice will not be heeded as all of your points are tinted versions of the same incorrect premises.

-----Original Message-----
From: Alex Besogonov
Sent: Feb 13, 2020 12:48 PM
To: Robert Engels
Cc: golang-nuts
Subject: Re: [go-nuts] Go without garbage collector

Then other languages should faithfully replicate C++ code. For example, iteration in Java should be done like this:

for( AtomicReference<Iterator> iter = arr.iterate(); iter.get().hasNext(); iter.get().next()) {

...

}

And no, reference counting is NOT a GC.

On Feb 13, 2020, at 10:45, Robert Engels <reng...@ix.netcom.com> wrote:

The C++ code is the original production code. The other languages were created from the C++ version.

Swift uses GC - it uses a reference counting GC which has been proven to be inferior compared to tracing collectors - especially in concurrent environments. Not to mention cycles.

Rust has multiple 'reference counting' based GC - and Rust ownership is essentially references counting of 1 with exclusive ownership.

Kotlin native uses GC as well - reference counting.

I suggest you tone it down a bit, and some more research would be helpful.

-----Original Message----- 
From: Alex Besogonov 
Sent: Feb 13, 2020 12:18 PM 
To: Robert Engels 
Cc: golang-nuts 
Subject: Re: [go-nuts] Go without garbage collector 

No. It doesn’t prove anything. The C++ code is badly written, as it creates completely superfluous objects (probably optimized away) and does an indirect lookup (which will NOT be). This needs to be fixed even if the code is a faithful translation of Java code. 

So in practice all the supposed benchmarks showing GC advantage are basically flawed.

Think about it, the newest popular languages: Swift, Rust and now Kotlin Native, - all have eschewed GC because it’s simply unworkable.

On Feb 13, 2020, at 06:05, Robert Engels <reng...@ix.netcom.com> wrote:

I understand that English may not be your primary language, but please reread the first sentence again. 

Beyond that you still miss the point. 

The code hasn’t been changed. The performance numbers have changed dramatically with no developer intervention. No “hand optimizing” required. 

The fact that C++ cant optimize that loop as written only proves my other points. They do in fact use that technique in the C++ code in many places - not all. Pretty typical what you will find in the real world. 

If you want to call Robert Hundt a hack, who are you???

On Feb 13, 2020, at 1:41 AM, alex.besogo...@gmail.com wrote:



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.

-- 

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