From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Lisp_Marker size on 32bit systems Date: Fri, 07 Sep 2018 21:54:50 -0400 Message-ID: References: <5a2c709e-aa49-b5b6-3fbe-fb8bd33acb23@cs.ucla.edu> <06d01a4b-9d98-df5b-be8a-aeda449acad7@cs.ucla.edu> <0e358c21-1e67-32f9-d24b-fa039753a2de@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1536371590 28486 195.159.176.226 (8 Sep 2018 01:53:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 8 Sep 2018 01:53:10 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 08 03:53:06 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fySQp-0007Gz-SD for ged-emacs-devel@m.gmane.org; Sat, 08 Sep 2018 03:53:03 +0200 Original-Received: from localhost ([::1]:40983 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fySSw-0006eh-Ca for ged-emacs-devel@m.gmane.org; Fri, 07 Sep 2018 21:55:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50328) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fySSp-0006ct-PX for emacs-devel@gnu.org; Fri, 07 Sep 2018 21:55:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fySSm-0000mH-IG for emacs-devel@gnu.org; Fri, 07 Sep 2018 21:55:07 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:54534) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fySSm-0000g7-B6 for emacs-devel@gnu.org; Fri, 07 Sep 2018 21:55:04 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w881soWY010157; Fri, 7 Sep 2018 21:54:51 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 645696A38A; Fri, 7 Sep 2018 21:54:50 -0400 (EDT) In-Reply-To: (Paul Eggert's message of "Fri, 7 Sep 2018 14:03:44 -0700") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6369=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6369> : inlines <6865> : streams <1797810> : uri <2705472> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:229464 Archived-At: >> I still wonder why it would be slower at all. > My guess is cache effects. My processor has a cache line size of 64 bytes, > so if objects are allocated in 32-byte chunks they won't straddle cache > boundaries and code will be less likely to thrash the cache. The difference of alignment is between multiples-of-8 and multiples-of-16, and allocation is done by the vectorlike code, so I think 32 byte objects aren't supposed to be much more likely to be aligned on 32 byte boundaries than on 32B + 16B. Hence, I don't find your argument very convincing. > I ran this benchmark in the 'lisp' subdirectory: > EMACSLOADPATH= perf stat -dd > '../src/emacs' -batch --no-site-file --no-site-lisp --eval '(setq > load-prefer-newer t)' -f batch-byte-compile org/org.el > > and am attaching the results for the 24-bit allocation (a bit slower) and > the 32-bit allocation (a bit faster), and they are in line with this guess. Those perf-stats also show improved I$ performance, which isn't explained by your suggested explanation. Similarly, they show a reduced number of instructions. IOW, I think there's something else at play than just the cache effects. >> it's not clear what the extra tags would be useful for. > Presumably to help performance elsewhere. Admittedly I'm blue-skying > a bit here. I think a 16 byte alignment could indeed be a good idea on 64bit systems (assuming we make the tags take advantage of it), but on 32bit systems where the memory is usually more constrained to start with, I think it would be a mistake. Stefan