From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by sourceware.org (Postfix) with ESMTPS id AA8B8393A41D for ; Mon, 1 Mar 2021 18:00:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AA8B8393A41D IronPort-SDR: vZDk6vCoo60ndkAdbdpnxpav760JZZ9ud0JaH6raqIkPVsmkTKBnyEf38YnKN9o/FHw4s+mzty Cnkrxb/J4oxw== X-IronPort-AV: E=McAfee;i="6000,8403,9910"; a="183150649" X-IronPort-AV: E=Sophos;i="5.81,215,1610438400"; d="scan'208";a="183150649" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Mar 2021 10:00:32 -0800 IronPort-SDR: npqUYjVOyuz5D4DR4tZW2t7b8A4WxsB99Nnj+BnzX60oTP8WuLi2boFfkb45hMSN1w6gPdrVuZ GTu/c9b7r0Gg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,215,1610438400"; d="scan'208";a="585582780" Received: from irsmsx605.ger.corp.intel.com ([163.33.146.138]) by orsmga005.jf.intel.com with ESMTP; 01 Mar 2021 10:00:30 -0800 Received: from tjmaciei-mobl1.localnet (10.255.230.217) by IRSMSX605.ger.corp.intel.com (163.33.146.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 1 Mar 2021 18:00:28 +0000 From: Thiago Macieira To: Thomas Rodgers CC: , , Subject: Re: C++2a synchronisation inefficient in GCC 11 Date: Mon, 1 Mar 2021 10:00:24 -0800 Message-ID: <7309459.cE9rBlv1QQ@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: References: <1968544.UC5HiB4uFJ@tjmaciei-mobl1> <812e6f42e4b6decfa864f12d73f42e5e@appliantology.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.255.230.217] X-ClientProxiedBy: orsmsx603.amr.corp.intel.com (10.22.229.16) To IRSMSX605.ger.corp.intel.com (163.33.146.138) X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_NUMSUBJECT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2021 18:00:35 -0000 On Monday, 1 March 2021 09:46:08 PST Thomas Rodgers wrote: > I discussed the prematureness of the contention optimization with ogiroux > this morning. Confirming, libc++ does do this, and in his measurements it > saves on the order of 50us. > > Regarding the use of _Hash_impl::hash(), that can be changed to just use the > pointer value itself. This is what libatomic does. I'm happy to propose > that as a subsequent patch to the most recent version of this code which I > submitted recently. Is the benchmark source somewhere I can take a look at? I'm worried that it is benchmarking the wrong thing. Can we benchmark latch and counting_semaphore instead? Those already track contention on the waitable atomic by themselves. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering