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 15:45:54 -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 1536349447 23369 195.159.176.226 (7 Sep 2018 19:44:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Sep 2018 19:44:07 +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 Fri Sep 07 21:44:03 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 1fyMfi-0005yN-Mw for ged-emacs-devel@m.gmane.org; Fri, 07 Sep 2018 21:44:02 +0200 Original-Received: from localhost ([::1]:40067 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fyMho-000259-Uh for ged-emacs-devel@m.gmane.org; Fri, 07 Sep 2018 15:46:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fyMhf-000250-5N for emacs-devel@gnu.org; Fri, 07 Sep 2018 15:46:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fyMhc-0005yX-Ck for emacs-devel@gnu.org; Fri, 07 Sep 2018 15:46:02 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:42543) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fyMhc-0005yA-77 for emacs-devel@gnu.org; Fri, 07 Sep 2018 15:46:00 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w87JjtEM001554; Fri, 7 Sep 2018 15:45:55 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id EF58F6A38A; Fri, 7 Sep 2018 15:45:54 -0400 (EDT) In-Reply-To: <0e358c21-1e67-32f9-d24b-fa039753a2de@cs.ucla.edu> (Paul Eggert's message of "Fri, 7 Sep 2018 12:04:16 -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 <6864> : streams <1797785> : uri <2705280> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:229446 Archived-At: >> Where does this 20% slow down come from? > Ha! It was because the 16-byte alignment caused pure space to overflow, > which disabled GC. No wonder there was such a big performance difference. OK, that makes more sense. > I fixed that, and now the patch to shrink marker allocations from 32 to 24 > bytes on x86 causes my standard benchmark (make compile-always) to run only > 1.0% slower, which is more reasonable. A microbenchmark of running > (make-marker) over and over again for 10,000,000 times runs 36% slower (815 > vs 597 ns for a single call). I still wonder why it would be slower at all. > Maybe we should be using 4 mark bits instead of 3? On 32bit systems, both cons cells and float cells use 8 bytes each, so aligning on multiples of 16 would double their memory use. And we currently have one free tag, so not only would using 4 tag bits significantly increase memory use for those objects, but it's not clear what the extra tags would be useful for. Also with the bignum support, the pressure to maximize the size of our fixnums is much lower, so we could even consider using fewer Lisp_Int tags if we feel like we need more tags. FWIW, IIUC XEmacs uses a 2bit tag which simply distinguishes between Lisp_Int0, Lisp_Int1, Char, and other objects. Since we don't have chars, that's like using a single-bit tag for us. Maybe we should introduce some way to instrument SYMBOLP/STRINGP/VECTORP/MARKERP/CONSP/... in order to try and figure out which objects are more deserving of having their tag right there in the Lisp_Object rather than just in the vectorlike_header. Stefan