public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 00/19] Add hash table to gdbsupport
Date: Thu, 11 Jan 2024 21:57:01 -0500	[thread overview]
Message-ID: <a7372c51-b9a4-4e2a-b55e-f5398b830fd1@simark.ca> (raw)
In-Reply-To: <87v87zpwuw.fsf@tromey.com>



On 2024-01-11 13:07, Tom Tromey wrote:
>>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:
> 
> [ new hash table ]
> 
> Tom> I'd like to move forward with this.
> 
> Tom> I think most of the patches here are straightforward.  The real question
> Tom> is whether we want it.  I've laid out my rationale in patch #1, with
> Tom> some additions (explaining why this is better than unordered_map /
> Tom> unordered_set) in a follow-up email.
> 
> I tried converting a few more libiberty hash tables to this one.
> 
> For a lot of things this is fine, big improvement, etc.
> 
> However, this hash table doesn't really admit the possibility that an
> element might not have a natural sentinel value.  This particularly
> comes up with hash maps, where if you want a std::string->whatever map,
> you have to introduce some kind of explicit sentinel (in my case I chose
> empty string) and also then have to write a trait class.
> 
> So, this is one area where unordered_map has the advantage.  Now, it
> would be possible to handle this in some way.  The hash table could
> store a sentinel flag, for instance.  Or, we could just accept this
> drawback and use unordered_map when convenience is important.
> 
> Anyway, I tend to think it's not an enormous issue, but I figured I'd
> point it out.
> 
> Tom

I spent a bit of time reading the interface of your hash table, and that
was a point I found unfortunate.  The type V must have a default
constructor and an "empty" state (I guess that's what you mean by
sentinel), even if it doesn't make sense for the rest of the program.

How do other implementations (of open addessing hash tables) typically
deal with this?  From what I recally, other implementations I have used
in the past didn't have this requirement.

And that makes me think that a question I did not see answered is: I
don't want to undermine your work, but what is the rationale for
implementing it ourselves?  Efficient C++ hash maps is a topic that
comes up all the time on various programming news sites (I found this
recent blog post after a quick google search [1]), surely that's a
solved problem.  Is there not a popular hash map library we can use
as-is?

Simon

[1] https://martin.ankerl.com/2022/08/27/hashmap-bench-01/

  parent reply	other threads:[~2024-01-12  2:57 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-07 15:25 Tom Tromey
2023-04-07 15:25 ` [PATCH 01/19] Add a " Tom Tromey
2023-04-07 15:41   ` Tom Tromey
2023-04-07 15:25 ` [PATCH 02/19] Convert compile-c-symbols.c to new hash table Tom Tromey
2023-04-07 15:25 ` [PATCH 03/19] Convert filename-seen-cache.h " Tom Tromey
2023-04-07 15:25 ` [PATCH 04/19] Convert linespec.c " Tom Tromey
2023-04-07 15:25 ` [PATCH 05/19] Convert target-descriptions.c " Tom Tromey
2023-04-07 15:25 ` [PATCH 06/19] Convert dwarf2/macro.c " Tom Tromey
2023-04-07 15:25 ` [PATCH 07/19] Convert breakpoint.c " Tom Tromey
2023-04-07 15:25 ` [PATCH 08/19] Convert py-framefilter.c " Tom Tromey
2023-04-07 15:25 ` [PATCH 09/19] Convert disasm.c " Tom Tromey
2023-04-07 15:25 ` [PATCH 10/19] Convert compile/compile.c " Tom Tromey
2023-04-07 15:25 ` [PATCH 11/19] Convert type copying " Tom Tromey
2023-04-07 15:25 ` [PATCH 12/19] Convert static links " Tom Tromey
2023-04-07 15:25 ` [PATCH 13/19] Convert gnu-v3-abi.c " Tom Tromey
2023-04-07 15:25 ` [PATCH 14/19] Convert abbrev cache " Tom Tromey
2023-04-07 15:25 ` [PATCH 15/19] Convert abbrevs " Tom Tromey
2023-04-07 15:25 ` [PATCH 16/19] Convert typedef hash " Tom Tromey
2023-04-07 15:25 ` [PATCH 17/19] Convert all_bfds " Tom Tromey
2023-04-07 15:25 ` [PATCH 18/19] Convert more DWARF code " Tom Tromey
2023-04-07 15:25 ` [PATCH 19/19] Convert gdb_bfd.c " Tom Tromey
2023-04-10 19:45 ` [PATCH 00/19] Add hash table to gdbsupport John Baldwin
2023-11-03 18:54   ` Tom Tromey
2023-12-08 18:28 ` Tom Tromey
2024-01-11 18:07   ` Tom Tromey
2024-01-11 19:35     ` John Baldwin
2024-01-12  2:57     ` Simon Marchi [this message]
2024-01-12 18:22       ` Tom Tromey
2024-01-12 19:12         ` Simon Marchi

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=a7372c51-b9a4-4e2a-b55e-f5398b830fd1@simark.ca \
    --to=simark@simark.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=tom@tromey.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).