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
>> <mailto: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
>>> <mailto: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
>>>
>>> <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
>>> <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
>>> <mailto: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
>>>
>>> <https://groups.google.com/d/msgid/golang-nuts/025972ea-042c-4ee9-9f11-8805e8104316%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/3A2270A9-1C1F-4D6C-9429-793799AE25BE%40gmail.com.
