From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26722 invoked by alias); 24 Jan 2012 16:03:34 -0000 Received: (qmail 26704 invoked by uid 22791); 24 Jan 2012 16:03:32 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Jan 2012 16:03:20 +0000 From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add Date: Tue, 24 Jan 2012 16:51:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-01/txt/msg02807.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51798 --- Comment #6 from Andrew Macleod 2012-01-24 16:02:03 UTC --- Others expressed concern about a change that could potentially affect all targets since its in libstdc++ code, especially considering this code is being deprecated. There are targets other than power that are also sensitive to the new semantics, both arm and alpha will change barrier emission based on the model used in fetch_and_add. I suggest acq-rel simply because it produces the same barrier structure power had in previous releases, is less intrusive, and is less likely to have an additional unforeseen impact anywhere else (other targets will also get the same barriers they had I believe.) You should see the same performance you had before wouldn't you? Im not arguing that using just release and acquire semantics instead wouldn't also be correct, merely that it is harder to prove the semantic change won't have unforeseen side effects in someones code. Its possible that relaxed mode might be also good enough, but again, harder to prove and comes with even greater risk. Anyway, just providing an option. It the libstdc++ guys that have to make the decision :-)