One other minor point on the proposed optimization, if this were a concurrent
collection you wouldn’t do this (eg a ConcurrentHashMap in Java) because the
end point changes.
So again, more cognitive load and maintenance issues in the C++ world as you
need far deeper knowledge of the systems (interface based design is not fully
possible if you want performance too).
> On Feb 13, 2020, at 8:05 AM, 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/B225A9C2-AE00-4426-A704-E8B25D36A3F8%40ix.netcom.com.
