From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F2B133858C60; Mon, 28 Feb 2022 17:24:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F2B133858C60 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance Date: Mon, 28 Feb 2022 17:24:27 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2022 17:24:28 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104719 --- Comment #7 from Jonathan Wakely --- (In reply to Vittorio Romeo from comment #4) > I like the idea of having the compiler itself fold calls to things like > `std::move` and `std::forward` as suggested in the linked > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96780.=20 That benefits user code too, so that users won't have to use static_cast in their own code because "std::move is slow". > But I think this issue I opened should be more general for any standard > library function that ends up impacting debug performance. Another common > example in the gamedev community is `std::vector`. Does the gamedev community actually use -Og though? Because if they only use -O0 (as is certainly the case for some) then the solution is "don't do that= ". Do they even use GCC/libstdc++ at all? Would they actually be more likely t= o if we change anything here? For those who are using -Og, adding always_inline to trivial accessors shouldn't be necessary, because GCC _should_ always inline them anyway. > In this benchmark, which uses `-Og`, you can notice a large performance > difference between a `std::vector` and `int*` dynamic array for > operations that I believe should have equal performance: > - https://quick-bench.com/q/lrS4I-lmDJ3VFP8L8rG2YHGXO-8 > - https://quick-bench.com/q/Uf-t79n7uYWAKdThOL_wxSp12Y0 >=20 > Are the above results also something that should be handled on the compil= er > side of things? Or would, for example, marking `std::vector::operator[]` = and > `std::vector::iterator::operator*` as `always_inline` remove the performa= nce > discrepancy? Somebody will have to investigate whether lack of inlining is the problem there. My guess would be that it's not due to trivial functions like op[] failing to be inlined, and so always_inline wouldn't help (except at -O0, b= ut "don't do that" if you need performance :-)=