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

Jonathan Wakely jwakely.gcc@gmail.com
Fri Nov 16 01:51:00 GMT 2012

On 15 November 2012 21:00, François Dumont wrote:
> On 11/14/2012 11:48 PM, Paolo Carlini wrote:
>> 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.

What if sizeof(functor) == 4, it will still be smaller than the size_t
hash code, right? (At least for common 64-bit platforms.) And if
sizeof(functor) == sizeof(size_t) it doesn't increase the footprint to
store the functor.  And if sizeof(functor) > sizeof(size_t) then could
we store a single copy of the functor somewhere and store a pointer to
it in each node? That would have the same size as the hash code, so we
never increase the size of a node by more than sizeof(functor*), and
the memory footprint is bounded. Is that possible?

Do we have any performance numbers showing the impact of different
sizes of functor stored in the nodes?

But anyway, surely non-empty functors are not the common case, so are
unlikely to be a performance problem for most users.

Do we have any idea why caching the hash code seems to be slower than
recalculating it?

>     Isn't gcc going to consider functor as noexcept even without the
> noexcept qualifier ? Analyzing the code gcc could guess it, no ?


You seem to be confusing what the optimisers can do and the
language-level `noexcept' operator.  The optimisers can do clever
analysis to change code generation, but the result of the noexcept
operator does not depend on such clever analysis. Try

void f() { }
static_assert( noexcept(f()), "" );

The assertion fails. Obviously this function cannot throw, but it is
not "noexcept"

Traits such as is_nothrow_constructible and move_if_noexcept and
__is_noexcept_hash depend *only* on the statically provable "noexcept"
property, *not* on how smart the optimisers are.

> And isn't
> adding noexcept going to change potential optimization of the functor ?

If anything, adding noexcept could help optimisation.

> Users might not being force to forget about optimization just to cache hash
> code or not.

I don't understand what you mean here, sorry.

If not caching always(?) makes things faster then it seems sensible to
only cache when we really need to (i.e. when the functor can throw)

More information about the Libstdc++ mailing list