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/B66CFF58-8163-4E4D-9E67-6FA3737ACE07%40ix.netcom.com.
