public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: Marek Polacek <polacek@redhat.com>
Cc: Tim Lange <mail@tim-lange.me>, GCC Mailing List <gcc@gcc.gnu.org>
Subject: Re: Usage of the C++ stdlib unordered_map in GCC
Date: Wed, 31 Aug 2022 10:37:42 +0100	[thread overview]
Message-ID: <CAH6eHdTDjA=-06biuQWkD+ZvFO1mz9xXQ4FTpa3ymw22PEr+0Q@mail.gmail.com> (raw)
In-Reply-To: <Yw5uFAZeTmhJV6LC@redhat.com>

On Tue, 30 Aug 2022 at 21:08, Marek Polacek via Gcc <gcc@gcc.gnu.org> wrote:
>
> On Tue, Aug 30, 2022 at 09:57:45PM +0200, Tim Lange wrote:
> > Hello,
> >
> > I was preparing a patch for GCC and used the unordered_map from the C++
> > stdlib in my patch. Later on, I noticed that it is used nowhere else inside
> > GCC except for some files in the go frontend.
> >
> > I wondered, now that building GCC requires a C++11 host compiler, whether
> > there is a consensus on which data structure implementation is preferred.
> > Should I rather use a hash_map instead of an unordered_map or is it on my
> > side to decide which one I choose?
>
> I think you're probably better off using a hash_map; std::unordered_map
> has efficiency issues as described in
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2028r0.pdf

I assume you mean the comments on page 6. Does GCC's hash_map actually
use open addressing and probing to deal with collisions? Do we want to
be able to change the hash function or use per-compilation salts?
(Would that break PCH?) If not, I don't see why it would be any better
when considering the metrics that paper is referring to. It might be
better based on other properties that benefit GCC, but the case
against std::unordered_map is often overstated.

If the question was whether to prefer std::unordered_map or
absl::node_hash_map then I would agree that std::unordered_map is a
bad choice. But that's not the question.

  reply	other threads:[~2022-08-31  9:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30 19:57 Tim Lange
2022-08-30 20:07 ` Marek Polacek
2022-08-31  9:37   ` Jonathan Wakely [this message]
2022-08-31 14:35     ` Jason Merrill
2022-08-31 14:35       ` Jason Merrill
2022-08-31 15:22       ` Tim Lange

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH6eHdTDjA=-06biuQWkD+ZvFO1mz9xXQ4FTpa3ymw22PEr+0Q@mail.gmail.com' \
    --to=jwakely.gcc@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=mail@tim-lange.me \
    --cc=polacek@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).