[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2

[Paolo Carlini]

Hi,

"François Dumont" <frs.dumont@gmail.com> ha scritto:

>On 11/14/2012 11:48 PM, Paolo Carlini wrote:
>> Hi,
>>
>> On 11/14/2012 10:27 PM, François Dumont wrote:
>>> We do not cache if the following conditions are all met:
>>> - key type is an integral
>>> - hash functor is empty and not final
>>> - hash functor doesn't throw
>> Can somebody remind me why *exactly* we have a condition having to do
>
>> with the empty-ness of the functor?
>
>     Because when hash code is not cache we need to embed the hash 
>functor into the local iterator implementation. So to minimize local
>implementation memory footprint we prefered to cache the hash code as
>soon as it is not empty.

Ok. Thus, if I understand correctly, we can have situations where the functor is non empty and even if it doesn't throw we want to cache to reduce the size of the local iterator, right? This case should be rather uncommon, a non empty functor. I don't think we should try particularly hard to minimize the size of local iterators... as usual, any idea what the other impls are doing in terms of that size?

>     Isn't gcc going to consider functor as noexcept even without the
>noexcept qualifier ? Analyzing the code gcc could guess it, no ? And
>isn't adding noexcept going to change potential optimization of the
>functor ?

The hint is indirect, without doubt, because IMHO the Standard itself is a little weak and vague in this area, and that isn't our implementors fault. That said, I think the idea will work in practice very consistently, because we know that if a function isn't marked explicitly noexcept the compiler isn't going to deduce anything, speaking of front-end, thus speaking of what your __is_noexcept_hash 'returns'. Middle end and back end can still optimize things but that doesn't matter for the 'value' of the trait. The are solid theoretical reasons for this, I did myself mistakes which I had to later correct when I tried to add some of that 'smartness' you are talking about to the internal front-end implementation of some traits (search Bugzilla for PRs filed by Martin Sebor and fixed by me). But please double check with some practical experiments!!!

In any case, I think we should aim for a simple rule, easy to write in the docs and explain, without too many exceptions, thus a too long list of features of the type and its functor. And we should also consider that performance wise many users out there are (or were) very happy with the legacy hash_set/hash_map and then the tr1 implementations, thus in terms of default behaviors I think we should stay pretty close.

Paolo