For those that are still interested in this...
-- An interesting point - when you run the Java or Go versions you will see CPU usage in excess of 100% - an indicator that the runtimes are parallelizing the work of GC with the application - something that (I don't believe) a malloc based application do (but conceivable it could predict potential fragmentation/oom conditions points and start asking the OS for more memory in the bg).
So not only is there additional memory consumption, but there is additional CPU usage as well - you don't have to code for the performance increases - but the costs as still there.
-----Original Message-----
From: Robert Engels
Sent: Feb 13, 2020 2:27 PM
To: ⚛ <0xe2.0x9a.0...@gmail.com>, golang-nuts
Subject: Re: [go-nuts] Go without garbage collectorI find it difficult to believe that--"However, on a desktop CPU with 32 MB of LLC, x86-64 mode, std::unordered_map has (if I am reading it correctly) 2.0e6 misses and std::map has 2.2e6 misses."level of cache misses is going to improve the total performance by 2x, but I can't really test. I am running all of the tests on the same hardware.But I ran the cpp today at work, on a machine with 8MB L3 and there was no difference between map and unordered_map.-----Original Message-----
From: ⚛ <0xe2.0x9a.0...@gmail.com>
Sent: Feb 13, 2020 1:23 PM
To: golang-nuts
Subject: Re: [go-nuts] Go without garbage collectorOn Thursday, February 13, 2020 at 7:02:37 PM UTC+1, Robert Engels wrote:--@atom ... I changed the cpp code to use unordered_map (cc and h) and it made the code slower... (iteration over most hash map implementations is slower than sorted maps since often you need to skip the unused key slots).It is more likely that if hash-map iteration is slower than sorted-map it is because of an increase in LLC (last-level cache) misses.So I would be very curious to see your code changes where this brought the performance to the level of Java ?It depends on the CPU used to run the benchmarks. In particular, a large L3 cache seems to help a lot.On a notebook CPU with 2 MB of LLC, x86-64 mode, the performance with std::unordered_map (849e6 LLC misses) indeed isn't better than std::map (605e6 misses).However, on a desktop CPU with 32 MB of LLC, x86-64 mode, std::unordered_map has (if I am reading it correctly) 2.0e6 misses and std::map has 2.2e6 misses.Changing the compiler target to x86-32 (gcc switch: -m32) improves performance on both CPUs.The complete git-diff in directory multi-language-bench/src/havlak/cpp, except #include directives, is:- typedef std::map<BasicBlock*, int> BasicBlockMap;+ typedef std::unordered_map<BasicBlock*, int> BasicBlockMap;- typedef std::map<int, BasicBlock*> NodeMap;+ typedef std::unordered_map<int, BasicBlock*> NodeMap;This is not my experience. Did you actually do this?It is probable some CPU performance counter can explain the difference in our experiences.-----Original Message-----
From: Robert Engels
Sent: Feb 13, 2020 11:33 AM
To: ⚛ <0xe2.0...@gmail.com>, golang-nuts
Subject: Re: [go-nuts] Go without garbage collectorI won't dispute that, but at least this particular case, it requires on-going maintenance by the developer (company). In this case of Java very few performance improvements have required code changes.Using a different structure entirely (hash map vs. tree map) is a different issue - it touches on the robustness of the stdlib, dynamic runtime class replacement, etc. I can only assume that std::map was used because it made the code easier/portable to write in C++ rather than adding an outside dependency or custom hash map. implementation (In the Java code, they use a custom IntegerSet, IntegerList to avoid boxing...)-----Original Message-----
From: ⚛ <0xe2.0...@gmail.com>
Sent: Feb 13, 2020 9:57 AM
To: golang-nuts
Subject: Re: [go-nuts] Go without garbage collectorOn Thursday, February 13, 2020 at 3:05:45 PM UTC+1, Robert Engels wrote:--The code hasn’t been changed. The performance numbers have changed dramatically with no developer intervention. No “hand optimizing” required.C++ evolves over time also. Hashmaps have been added to C++ in C++11, which from today's viewpoint invalidates most benchmarks published before year 2011 that translated Java's HashMap to C++'s std::map.
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/f5a4a3cf- .e4ce-4fb4-af03-fa5f32a5ce62% 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 golan...@googlegroups.com .
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1149226989. .3184.1581615195727%40wamui- sophie.atl.sa.earthlink.net
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/b4dadd10-e44c-458c-9d27-fbd3d7e6ba93%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/1087935131.4244.1581625624369%40wamui-sophie.atl.sa.earthlink.net.
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/683360176.4373.1581626961270%40wamui-sophie.atl.sa.earthlink.net.