From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: [PATCH v2 00/16] Speeding up DEFVAR_PER_BUFFER Date: Mon, 30 Nov 2020 22:26:42 +0000 Message-ID: References: <20201119153814.17541-1-sbaugh@catern.com> <837dqdxtea.fsf@gnu.org> <87a6v9jqz8.fsf@catern.com> <83y2itwbzk.fsf@gnu.org> <87ft4shxg8.fsf@catern.com> <835z5mk84w.fsf@gnu.org> <87y2iihafg.fsf@catern.com> Reply-To: Andrea Corallo Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28433"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Spencer Baugh , Eli Zaretskii , dgutov@yandex.ru, arnold@tdrhq.com, rms@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 30 23:28:03 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kjreM-0007F6-Ml for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Nov 2020 23:28:02 +0100 Original-Received: from localhost ([::1]:43762 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjreL-0001o6-Pu for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Nov 2020 17:28:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39546) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjrdO-00014F-7I for emacs-devel@gnu.org; Mon, 30 Nov 2020 17:27:02 -0500 Original-Received: from mab.sdf.org ([205.166.94.33]:42720 helo=ma.sdf.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjrdM-0007mF-HN; Mon, 30 Nov 2020 17:27:01 -0500 Original-Received: from akrl by ma.sdf.org with local (Exim 4.92) (envelope-from ) id 1kjrd4-00050c-SQ; Mon, 30 Nov 2020 22:26:42 +0000 In-Reply-To: (Stefan Monnier's message of "Mon, 30 Nov 2020 17:10:20 -0500") Received-SPF: pass client-ip=205.166.94.33; envelope-from=akrl@sdf.org; helo=ma.sdf.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:260100 Archived-At: Stefan Monnier writes: >> Yes, it's probably a trade-off. My guess is that the extra overhead of >> BVAR will not be significant, but benchmarking is the only way to know >> for sure. (Indeed, it's possible things will speed up by removing the >> metadata, which reduces the size of the working set and lets more things >> stay in cache) > > Maybe one way to figure it out is to magnify the impact: add extra > slowdown code to BVAR to make sure the slowdown is noticeable. > This might point to the place where a performance impact may be > measurable, or it might make it obvious that the impact is negligible. > >> Well, with a completely naive static branch-predictor which assumes the >> Qunbound branch will never be taken, there will be no overhead for >> fields which are never Qunbound, namely non-DEFVAR_PER_BUFFER fields and >> permanent-buffer-locals. We could encourage that prediction by marking >> the Qunbound branch with an "unlikely()" macro using GCC's >> __builtin_expect. > > While this might work for some vars, I suspect that it could be > detrimental for some. > >> It's probably prematurely low-level for me to talk about such things >> right now though - benchmarking is the only way to know. > > 100% agreement. And modern branch predictors are quite sophisticated so > I expect they'll do a much better job than any hint we may be able > to provide. Is not possible to provide hints to the branch predictor. The __builtin_expect is used only to hint GCC to reorder basic blocks so that the most likely execution path is going to be sequential, this to maximize i-cache efficiency. I doubt a single __builtin_expect will have a measurable impact here. Andrea