- Niuce C++14-feature - 4 Updates
- std::unordered_map<Key,T,Hash,KeyEqual,Allocator>::emplace_hint - 15 Updates
| David Brown <david.brown@hesbynett.no>: May 22 04:18PM +0200 On 21/05/2021 18:25, Scott Lurndal wrote: >> Your knowledge is very superficial when it comes to parallelization ! > You are both arguing past each other. > Both forking and multithreading are useful in the right situation. Yes - that is so obvious that it is hard to understand how these two can be having an argument. Forking is best when you need separation between the parts and they should have little connection - sshd was given as an example. It is also good if there is a risk of crashing or security breaches, as failures will not be as catastrophic. Threading is best when you have threads working together to improve the throughput of a single task or need lots of communication and shared data. So for some tasks, one choice is obviously much better than the other, for other tasks either will work, or a combination, or other factors dominate. But arguing whether multithreading or forking is best is like arguing whether trains or planes are best. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 22 04:25PM +0200 > But arguing whether multithreading or forking is best is like arguing > whether trains or planes are best. Mostly you have a lot of coupling when you have parallel code. Then fork()ing is a lot of work and less efficient. |
| "Öö Tiib" <ootiib@hot.ee>: May 22 08:44AM -0700 On Saturday, 22 May 2021 at 17:25:43 UTC+3, Bonita Montero wrote: restoring attribution > > whether trains or planes are best. > Mostly you have a lot of coupling when you have parallel code. > Then fork()ing is a lot of work and less efficient. The goal of reducing coupling to as close as it is possible to embarrassingly parallel is same to both. Otherwise the threads will just hang behind semaphores most of the time and the whole concurrency was futile waste of development time into producing pointlessly complicated code and to achieve drop in efficiency. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 22 05:49PM +0200 > The goal of reducing coupling to as close as it is possible to > embarrassingly parallel is same to both. embarrassingly parallel doesn't automatically mean there's not much coupling. There could be a lot of shared data f.e.. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 22 08:14AM +0200 > Even if implementation ignores that hint there is slight performance > potential as it returns only iterator not pair<iterator,bool> like emplace. But you hand over an additional iterator, which outweighs this advantage. |
| "Öö Tiib" <ootiib@hot.ee>: May 22 02:11AM -0700 On Saturday, 22 May 2021 at 09:14:26 UTC+3, Bonita Montero wrote: > > potential as it returns only iterator not pair<iterator,bool> like emplace. > But you hand over an additional iterator, which outweighs > this advantage. Groundless assertion noted. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 22 11:23AM +0200 >> But you hand over an additional iterator, which outweighs >> this advantage. > Groundless assertion noted. Imagine the simplest case when the iterator is simply a pointer internally. Moving a pointer has the same cost on todays CPUs than a bool. |
| "Öö Tiib" <ootiib@hot.ee>: May 22 03:32AM -0700 On Saturday, 22 May 2021 at 12:23:48 UTC+3, Bonita Montero wrote: > Imagine the simplest case when the iterator is simply a pointer > internally. Moving a pointer has the same cost on todays CPUs > than a bool. I understand that imagination was ground to your shallow claim. But fruits of imagination are better dismissed in engineering. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 22 12:43PM +0200 >> than a bool. > I understand that imagination was ground to your shallow claim. > But fruits of imagination are better dismissed in engineering. You're arrogant and stupid. Look at this code: #include <unordered_map> #include <utility> using namespace std; using umi_t = unordered_map<int, int>; using umi_it = umi_t::iterator; pair<umi_it, bool> f123( umi_t &um ) { return pair<umi_it, bool>( um.begin(), true ); } umi_it f456( umi_t &um ) { return um.begin(); } This results in this: .file "x.cpp" .text .p2align 4,,15 .globl _Z4f123RSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEE .type _Z4f123RSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEE, @function _Z4f123RSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEE: .LFB1603: .cfi_startproc movq 16(%rdi), %rax movl $1, %edx ret .cfi_endproc .LFE1603: .size _Z4f123RSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEE, .-_Z4f123RSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEE .p2align 4,,15 .globl _Z4f456RSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEE .type _Z4f456RSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEE, @function _Z4f456RSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEE: .LFB1621: .cfi_startproc movq 16(%rdi), %rax ret .cfi_endproc .LFE1621: .size _Z4f456RSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEE, .-_Z4f456RSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEE .ident "GCC: (Debian 6.3.0-18+deb9u1) 6.3.0 20170516" .section .note.GNU-stack,"",@progbits So the difference is just one move as I told. And as you can see from the abvove, an iterator is just a pointer for this container. And passing a hint-iterator would be just an additional move. So the additional bool is outweight by the hint. |
| "Öö Tiib" <ootiib@hot.ee>: May 22 05:11AM -0700 On Saturday, 22 May 2021 at 13:43:45 UTC+3, Bonita Montero wrote: > > I understand that imagination was ground to your shallow claim. > > But fruits of imagination are better dismissed in engineering. > You're arrogant and stupid. You are mirroring how you feel yourself to me. > Look at this code: I wrote "Even if implementation ignores that hint there is slight performance potential as it returns only iterator not pair<iterator,bool> like emplace. " You groundlessly claimed that passing (allegedly unused) iterator there somehow outweights that advantage. To my dismissing of your groundless claims you now just demonstrate inability to profile difference of performance of emplace_hint and emplace of unordered_map implementation that ignores that hint (AFAIK msvc does). How I am arrogant and stupid? I was simply correct that you pull your claims out from ignorance and imagination and you yourself demonstrated it to everybody. |
| "daniel...@gmail.com" <danielaparker@gmail.com>: May 22 05:28AM -0700 On Friday, May 21, 2021 at 5:29:26 PM UTC-4, Öö Tiib wrote: > > looks to me like a total nonsense-API. > Some code that used map can be faster and with less changes switched > to use of unordered_map. Who does that? Microsoft doesn't. gcc doesn't. Microsoft and gcc share implementation details between unordered_map and unordered_multimap, not map. And even there, the shared code doesn't leak into the interface, it's introduced as a data member that unordered_map and unordered_multimap both delegate to. And why would the Standard, which mandates emplace_hint in both container types, care about these implementation details? No, the only reason that emplace_hint appears in both unordered_map, where it's useless, and unordered_multimap, where it makes some sense with equivalent keys, is because the Standard mandated that both container types satisfy the same type requirement "unordered associative container". Daniel |
| Bonita Montero <Bonita.Montero@gmail.com>: May 22 02:46PM +0200 > I wrote "Even if implementation ignores that hint there is slight > performance potential as it returns only iterator not > pair<iterator,bool> like emplace. " Yes, and I've shown that the difference is just an move-instruction. And this is the same difference when passing hint. > You groundlessly claimed that passing (allegedly unused) iterator > there somehow outweights that advantage. Yes, because this is a identical move. > How I am arrogant and stupid? ... Yes, ultra-stupid. |
| "Öö Tiib" <ootiib@hot.ee>: May 22 05:54AM -0700 > Who does that? Microsoft doesn't. gcc doesn't. Microsoft and gcc share > implementation details between unordered_map and unordered_multimap, > not map. Sorry for me not expressing myself clearly enough. I mean I do it. Usage of std::map for dictionary to what alphabetic orders of keys does not matter is unfortunately common. If searches to such dictionary show up as factor in profiler then I propose to switch to unordered_map. That work can be so small as replacing: using RecordDictionary = std::map<std::string, Record>; with: using RecordDictionary = std::unordered_map<std::string, Record>; and then running tests and then profiling. But if emplace_hint of RecordDictionary was used in code then the tests would not compile and so more changes would be needed. |
| "Öö Tiib" <ootiib@hot.ee>: May 22 05:57AM -0700 On Saturday, 22 May 2021 at 15:46:58 UTC+3, Bonita Montero wrote: > Yes, because this is a identical move. > > How I am arrogant and stupid? ... > Yes, ultra-stupid. All your life you are doomed to claim groundless garbage and then to run from discussions with pathetic insults. Does it feel good? |
| Bonita Montero <Bonita.Montero@gmail.com>: May 22 03:04PM +0200 > All your life you are doomed to claim groundless garbage ... You could say that if you'd understand what I told. But you didn't. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 22 03:06PM +0200 > and then running tests and then profiling. > But if emplace_hint of RecordDictionary was used in code then > the tests would not compile and so more changes would be needed. I think it's not really because of that because the hint-parameter could be removed in a blink of an eye. I think it's about generic code interfacing to generic containers which need this identical interface-specification. |
| "Öö Tiib" <ootiib@hot.ee>: May 22 06:51AM -0700 On Saturday, 22 May 2021 at 16:05:15 UTC+3, Bonita Montero wrote: > > All your life you are doomed to claim groundless garbage ... > You could say that if you'd understand what I told. > But you didn't. Such empty screams of disagreeing "No!" and "No I didnt!" are integral part of the song "So brave sir robin ran away, bravely ran away away..." <https://www.youtube.com/watch?v=BZwuTo7zKM8> |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: May 22 07:49AM -0700 > All your life you are doomed to claim groundless garbage and > then to run from discussions with pathetic insults. Does it feel > good? Which brings up the question, why then do you bother responding? Or even reading the posts to begin with? |
| "Öö Tiib" <ootiib@hot.ee>: May 22 08:23AM -0700 On Saturday, 22 May 2021 at 17:49:52 UTC+3, Tim Rentsch wrote: > > good? > Which brings up the question, why then do you bother responding? > Or even reading the posts to begin with? The idea that profiling of real thing can be replaced with imagination and guessing is indeed quite common and boring mistake that perhaps does not deserve discussions. Otherwise I'm just reading a book and as it is Saturday am not too busy with anything. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment