From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) by sourceware.org (Postfix) with ESMTPS id B82123858D28; Fri, 15 Mar 2024 02:06:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B82123858D28 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=protonmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=protonmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B82123858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.70.43.16 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710468411; cv=none; b=Qf1rF/h6zMzrnCn8cOrEBmvaGq7wWoeYqtnxU0Wf3VsvYPLyZ4NqmXRzXZzwJwPeUHTPCWFPOv8hMALFFA/+n6STmyJal0M7N0UrteCzcUCkaVYfDjAZnNaQBwOub1OKeZijOGGrvHCOxUJu312xGHernkg723Z6yqvQ4PLy6Y8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710468411; c=relaxed/simple; bh=rvRk172FFwjK4Isgqq4ZZ8BxKa8EcH8dcMW7DIMiN5E=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=VcPtfwVkRFQJlmNr17/UOO/1JNJ9og3Irdq7hSnRhNE0BateoG9Qn6xVOgi1PhEoUWg+t37YzQr7To6PSP63Sg4ykTO7CiOonMTtc1b6SOQsR8tfYLaXmij5UZdcvAwxNf5QVPsQsEA7J1NMP5Q0l3ykBQDL/VCb71Zl+jblffs= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1710468408; x=1710727608; bh=/Fob/aUpBBTqZ8vBB5ESqJHlEhBsjdwBuRoa3THM5hU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=SbIYI6R71RlkqiXnZp3Tmh39e/dJLxXEvlCntmNCfqQPuZJq/KF+by/jRwx5Y2LwR EPJ2l2WlnicHXaoiUHHDg39noCh8hDRMpMngPezD+6fQFFTlndPGJ/T9j9G8EoUz52 G42iEvyyPs9u7QH68LwSC9c5fYdMg5ZsYIEyQMGFacC2D2iu6EGP2eUcHCRzpGJYW/ r1crH/82ncb0BClC24ShprNVueqmJDdOwN73xmPnyOJbAHwRBukQnmU6M9EYbveY4E AyBfAcoBCtbmpPUxsG+Cd1/EKgZXQiVvThOiV/umwDEFEZxUJz1WwjgEQWsyUMyF46 9hWWkljPNaiVg== Date: Fri, 15 Mar 2024 02:06:29 +0000 To: Jonathan Wakely From: =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH v1] libstdc++: Optimize removal from unique assoc containers [PR112934] Message-ID: In-Reply-To: References: <20240311233548.3705328-1-pobrn@protonmail.com> Feedback-ID: 20568564:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,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: Hi 2024. m=C3=A1rcius 13., szerda 12:43 keltez=C3=A9ssel, Jonathan Wakely =C3=ADrta: > On Mon, 11 Mar 2024 at 23:36, Barnab=C3=A1s P=C5=91cze wrote: > > > > Previously, calling erase(key) on both std::map and std::set > > would execute that same code that std::multi{map,set} would. > > However, doing that is unnecessary because std::{map,set} > > guarantee that all elements are unique. > > > > It is reasonable to expect that erase(key) is equivalent > > or better than: > > > > auto it =3D m.find(key); > > if (it !=3D m.end()) > > m.erase(it); > > > > However, this was not the case. Fix that by adding a new > > function _Rb_tree<>::_M_erase_unique() that is essentially > > equivalent to the above snippet, and use this from both > > std::map and std::set. >=20 > Hi, this change looks reasonable, thanks for the patch. Please note > that GCC is currently in "stage 3" of its dev process so this change > would have to wait until after GCC 14 branches from trunk, due in a > few weeks. OK; I didn't know that, thanks for telling me. >=20 > I assume you ran the testsuite with no regressions. [...] I hope so. I ran `make check-target-libstdc++-v3`, and it did not note any unexpected failures as far as I can see: Native configuration is x86_64-pc-linux-gnu =09=09=3D=3D=3D libstdc++ tests =3D=3D=3D Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file fo= r target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for ta= rget. Using /gcc/libstdc++-v3/testsuite/config/default.exp as tool-and-target-s= pecific interface file. Running /gcc/libstdc++-v3/testsuite/libstdc++-abi/abi.exp ... Running /gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... Running /gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinte= rs.exp ... Running /gcc/libstdc++-v3/testsuite/libstdc++-xmethods/xmethods.exp ... =09=09=3D=3D=3D libstdc++ Summary =3D=3D=3D # of expected passes=09=0918646 # of expected failures=09=09126 # of unsupported tests=09=09672 > [...] Do you have benchmarks to show this making a difference? As for benchmarks, I do not have any. But even if the performance does not improve appreciably, the size of the generated code will definitely be smal= ler. And in the end, the excessive code was the reason I opened the mentioned is= sue[0] in the first place, which should be eliminated hopefully. > [...] Regards, Barnab=C3=A1s P=C5=91cze [0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112934