This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
- From: Paolo Carlini <paolo dot carlini at oracle dot com>
- To: François Dumont <frs dot dumont at gmail dot com>
- Cc: Jonathan Wakely <jwakely dot gcc at gmail dot com>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 14 Nov 2012 00:11:12 +0100
- Subject: Re: [Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
- References: <bug-54075-19885@http.gcc.gnu.org/bugzilla/> <bug-54075-19885-8bKDxmpStr@http.gcc.gnu.org/bugzilla/> <509ADA7E.7050504@gmail.com> <CAH6eHdRHCefZq1FQF64nJ04-OMgMBb8TeUa5y9Lvi-2H=xE0Ww@mail.gmail.com> <509B1130.7050401@oracle.com> <509B1834.5080106@oracle.com> <509C21B9.3070703@gmail.com> <509CE00A.1040704@oracle.com> <50A2BE5B.3030809@gmail.com> <50A2CF71.5060804@oracle.com>
On 11/13/2012 11:53 PM, Paolo Carlini wrote:
To summarize my intuitions are (again, leaving out the final
technicalities)
a- std::hash specializations for scalar types -> no cache
b- std::hash specialization for for std::string (or maybe
everything else, for simplicity) -> cache
c- user defined functor -> cache or not basing on __is_noexcept_hash
Alternately, if we want to stress the consistency of our behavior, just
a single rule: __is_noexcept_hash. That means I expect that b- above is
normally penalized performance-wise, but we can document the behavior,
the user can simply instantiate with a user defined hash functor which
doesn't have noexcept on the call operator and just forwards to
std::hash<std::string> and switch the container to caching.
Paolo.