From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id E69283858D39 for ; Wed, 31 Aug 2022 14:35:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E69283858D39 Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-665-_ddHZ5hsNFGFVxMFH1UtZA-1; Wed, 31 Aug 2022 10:35:21 -0400 X-MC-Unique: _ddHZ5hsNFGFVxMFH1UtZA-1 Received: by mail-ed1-f72.google.com with SMTP id m15-20020a056402430f00b00448af09b674so4322116edc.13 for ; Wed, 31 Aug 2022 07:35:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=+FDuKyXQHMmMXFXFtuRMVEdUPqxONXdOGhVwNBXL0T0=; b=60TjuebsaJvLu9K+xylcM+DJDrjA+5Q4ueFdsav6O9pIN6v2+TFmgNWAVplpdfOQnU 8uvk/WtKbiTcKXGsPL73hcRKrLBYKMQyP0bsRQvK9V2a5dYiK6HtxNbYAUkyLdvNPmtI v49+BphUXH22vMfK8Xt0w5UTI0lY0inZTR4EkPmcfN960810OTCoi4beayBXyfJ9Zdvx A0gX7Cce3jRVgNxlfK/26JPiaBSfTE3dcvYTAUuRLsGXgBO/1PIksqbO+sJgfdjzLGL1 ebM2Mqq+HRHAK2xs/svqPsO/bPVZKNf70MGY4lPpmD65e1l1jdhFYnEDJIVdRTbMq4iv WzHA== X-Gm-Message-State: ACgBeo1XZJKspqXni7/GrdRo2ZEVzQ2Tffv/zptkVzFbk774qk9Mgmqi +84zXvnHt+EW1FN7Jal2YQweLpNU7sf3Ie1fmYgUpj1od/NmU+Fw3E/02c3tauDt3+t/o6m+1Ru Ziw16LTG/Tbnipns8iHvNP4I= X-Received: by 2002:a05:6402:5242:b0:448:6849:7e1e with SMTP id t2-20020a056402524200b0044868497e1emr13368100edd.137.1661956520513; Wed, 31 Aug 2022 07:35:20 -0700 (PDT) X-Google-Smtp-Source: AA6agR6zBNFb7R9WFx2MWCJvwFzbblfSAJvvgjk5Sody0zLrjhpEPnfu/3e5HztLpEWceBKa5ewr6tLGsNgPXtIqDhs= X-Received: by 2002:a05:6402:5242:b0:448:6849:7e1e with SMTP id t2-20020a056402524200b0044868497e1emr13368078edd.137.1661956520222; Wed, 31 Aug 2022 07:35:20 -0700 (PDT) MIME-Version: 1.0 References: <942GHR.WGPY8O255349@tim-lange.me> In-Reply-To: From: Jason Merrill Date: Wed, 31 Aug 2022 10:35:08 -0400 Message-ID: Subject: Re: Usage of the C++ stdlib unordered_map in GCC To: Jonathan Wakely Cc: Marek Polacek , GCC Mailing List X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2022 14:35:26 -0000 On Wed, Aug 31, 2022 at 5:38 AM Jonathan Wakely via Gcc wrote: > On Tue, 30 Aug 2022 at 21:08, Marek Polacek via Gcc > 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. > Generally we want to use the GCC hash_map because it works with GCC garbage collection (and PCH). Is that not relevant to your patch? Jason From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id E69283858D39 for ; Wed, 31 Aug 2022 14:35:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E69283858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661956523; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+FDuKyXQHMmMXFXFtuRMVEdUPqxONXdOGhVwNBXL0T0=; b=AfT0VW3vfjvtD2HBc/iIvn9kyVscub42KA6h54WDseFuQxRk/3efUIeKYTJW1vaoRK0+Re bzJUGaeEcrXGytK6SVZRwtN6t57SHXtjCkM0p6In+bLR3sUYuRe0lFFg5F9Xk1UEMHCr+H j0y3eq/BlMZU+3lmSFT2+lTTINVhU+8= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-665-_ddHZ5hsNFGFVxMFH1UtZA-1; Wed, 31 Aug 2022 10:35:21 -0400 X-MC-Unique: _ddHZ5hsNFGFVxMFH1UtZA-1 Received: by mail-ed1-f72.google.com with SMTP id m15-20020a056402430f00b00448af09b674so4322116edc.13 for ; Wed, 31 Aug 2022 07:35:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=+FDuKyXQHMmMXFXFtuRMVEdUPqxONXdOGhVwNBXL0T0=; b=60TjuebsaJvLu9K+xylcM+DJDrjA+5Q4ueFdsav6O9pIN6v2+TFmgNWAVplpdfOQnU 8uvk/WtKbiTcKXGsPL73hcRKrLBYKMQyP0bsRQvK9V2a5dYiK6HtxNbYAUkyLdvNPmtI v49+BphUXH22vMfK8Xt0w5UTI0lY0inZTR4EkPmcfN960810OTCoi4beayBXyfJ9Zdvx A0gX7Cce3jRVgNxlfK/26JPiaBSfTE3dcvYTAUuRLsGXgBO/1PIksqbO+sJgfdjzLGL1 ebM2Mqq+HRHAK2xs/svqPsO/bPVZKNf70MGY4lPpmD65e1l1jdhFYnEDJIVdRTbMq4iv WzHA== X-Gm-Message-State: ACgBeo1XZJKspqXni7/GrdRo2ZEVzQ2Tffv/zptkVzFbk774qk9Mgmqi +84zXvnHt+EW1FN7Jal2YQweLpNU7sf3Ie1fmYgUpj1od/NmU+Fw3E/02c3tauDt3+t/o6m+1Ru Ziw16LTG/Tbnipns8iHvNP4I= X-Received: by 2002:a05:6402:5242:b0:448:6849:7e1e with SMTP id t2-20020a056402524200b0044868497e1emr13368100edd.137.1661956520513; Wed, 31 Aug 2022 07:35:20 -0700 (PDT) X-Google-Smtp-Source: AA6agR6zBNFb7R9WFx2MWCJvwFzbblfSAJvvgjk5Sody0zLrjhpEPnfu/3e5HztLpEWceBKa5ewr6tLGsNgPXtIqDhs= X-Received: by 2002:a05:6402:5242:b0:448:6849:7e1e with SMTP id t2-20020a056402524200b0044868497e1emr13368078edd.137.1661956520222; Wed, 31 Aug 2022 07:35:20 -0700 (PDT) MIME-Version: 1.0 References: <942GHR.WGPY8O255349@tim-lange.me> In-Reply-To: From: Jason Merrill Date: Wed, 31 Aug 2022 10:35:08 -0400 Message-ID: Subject: Re: Usage of the C++ stdlib unordered_map in GCC To: Jonathan Wakely Cc: Marek Polacek , GCC Mailing List X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="00000000000005351405e78a681c" X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Message-ID: <20220831143508.6WEtiuHW4sWmMDm3MsB3lI7Qc0Wm32BTeO6Y4-TrzZs@z> --00000000000005351405e78a681c Content-Type: text/plain; charset="UTF-8" On Wed, Aug 31, 2022 at 5:38 AM Jonathan Wakely via Gcc wrote: > On Tue, 30 Aug 2022 at 21:08, Marek Polacek via Gcc > 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. > Generally we want to use the GCC hash_map because it works with GCC garbage collection (and PCH). Is that not relevant to your patch? Jason --00000000000005351405e78a681c--