From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master f18af6c: Audit use of lsh and fix glitches Date: Fri, 24 Aug 2018 18:00:10 +0000 Message-ID: References: <20180821204437.16880.99611@vcs0.savannah.gnu.org> <20180821204439.62390209A6@vcs0.savannah.gnu.org> <53d0c06e-2383-955a-0a17-650fd842b483@cornell.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1535133579 14754 195.159.176.226 (24 Aug 2018 17:59:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Aug 2018 17:59:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 24 19:59:35 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 1ftGMx-0003iu-EV for ged-emacs-devel@m.gmane.org; Fri, 24 Aug 2018 19:59:35 +0200 Original-Received: from localhost ([::1]:42941 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftGP3-0001mF-9O for ged-emacs-devel@m.gmane.org; Fri, 24 Aug 2018 14:01:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftGOC-00010U-IU for emacs-devel@gnu.org; Fri, 24 Aug 2018 14:00:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ftGOA-0001Fh-Ta for emacs-devel@gnu.org; Fri, 24 Aug 2018 14:00:52 -0400 Original-Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]:40699) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ftGOA-0001Cc-HF for emacs-devel@gnu.org; Fri, 24 Aug 2018 14:00:50 -0400 Original-Received: by mail-lj1-x231.google.com with SMTP id j19-v6so7526568ljc.7 for ; Fri, 24 Aug 2018 11:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w6iPJqSW6Gmyp9LVorKuCkWIIvfxNhX41s7arNu4UNg=; b=aUrGPJt6W+xRlRxbhvKmPzJ27BC9uNOJ/wc05pmqih/ndmqKON+D8ATvqIwXBHk+di vWyRufeUpDOgyREiwCds+rcCiYk1RHA4YkW5V7st3SVBwygxFBX38dyL4ItVaSRBAuTJ 84YluJh6QUqKpAqU1wafQv3F/bxS39m3kA+F88DQAve2o6nrTBSemXbvFnVn/TTeyzmw j3FZxjqqCW9cDCbX/9qJSNA5meqPYtaV6ZNvXuHIhXFk1d3ORxjRpked9K6rTKbl6jGv 3whEcz20SeKK4MPg3RXtVRhdb7v2Suz8FnraGmSOMyVv0Q37pWPnMTOE6OnUUax2ZdHh ti5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w6iPJqSW6Gmyp9LVorKuCkWIIvfxNhX41s7arNu4UNg=; b=rOfSEC2tPR31MVIhdJssnHAdy//gh8dKgHFMB73TjMKAXJl/9OhjHN2FATXv1J45Mr PdWBIrVR0WShRp8zzyCawsx26FxUxSuFzbt7lVi2bwzLTnBw5VcS3yI2CqqRtL6wFNE0 ICoPI+Sck5fJRsFcu9T6Wtb7LNr8hWo+v0A+v8zO25FGTz0HGqVfZW5aqXH12pyAIPPJ 3AguZQTY69MmA/nWXpdLW6k38Zvjcdwqry0CIbmLUuEq04avxMwdOeph4B1w/WQypRYU Bkyp8H+UNhccLiuq3exp0HNjSLbQbUitHanKDUrFFF+9QqDoSpFHJKl8OV+BkIfC9n3O SX7Q== X-Gm-Message-State: APzg51DRaHjJL61OAJPkO1SGnWgpyjFPIa51f3jMSYrroWMdgueQBDhC jY7SehlL4yifk3MBOm5BbI2RxQOfaton7I1oUafZeg== X-Google-Smtp-Source: ANB0VdYWh7ekefJKAiaPaZYfsX56s1KJWJHg1wrfJwFT0Az3gRqQuB06IFFPeLoRYinwl071IqsyU89EnlLWIFI4cy4= X-Received: by 2002:a2e:998e:: with SMTP id w14-v6mr2015892lji.7.1535133647932; Fri, 24 Aug 2018 11:00:47 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::231 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:228874 Archived-At: On Thu, Aug 23, 2018 at 3:56 PM Stefan Monnier wrote: > > Well, it isn't `==' if we're building with > > --enable-check-lisp-object-type, > > Currently, the resulting assembly code should be pretty close even in > that case, tho. Okay; I wasn't sure whether we were talking about a literal "people use == on Lisp_Objects" problem or not. The resulting assembly code is indeed equivalent to a `==', it seems. > The whole purpose of hash-consing (for me) is to avoid turning EQ into > something like: > > if (BIGNUMP (x)) > return slow_eq (x, y); > else > return x == y; > > What we do in slow_eq is largely irrelevant: the problem is the cost of > `if (BIGNUMP (x))`, both in terms of code size and processing time. I understand that. In fact, the cost is fairly (and, to me, surprisingly) high, about 1%. That is, indeed, way more than I thought, and I'll have to look at the assembler code to figure out why it's so expensive. But what I want is only about one tenth as bad (in terms of code size) as what you describe: the code you don't want: 13 .text 00227f8e 0000000000419a00 0000000000419a00 00019a00 2**4 the code you do want (i.e. vanilla): 13 .text 001d945e 0000000000419a00 0000000000419a00 00019a00 2**4 the code I want: 13 .text 001e0b3e 0000000000419a00 0000000000419a00 00019a00 2**4 (I got it down to 24816 bytes of code size difference with another compiler, but still using the standard make flags on an x86_64 pc-linux-gnu system.) The performance penalty is a quarter of a clock cycle per problematic EQ, on this machine, though obviously anything in that range depends on your precise CPU architecture and surrounding insns that affect superscalar scheduling. We call EQ a lot, there are between 15 and 32 billion problematic calls in the temacs/emacs invocations to rebuild all .elc files in the Emacs distribution. ("problematic" means that gcc wasn't able to prove that one argument to EQ couldn't possibly be a bignum, and had to emit a conditional branch insn). So that also works out to something in the 1% range. (However, upon inspection it turns out that adding the debugging code makes gcc fail to optimize away many of the problematic calls, so the actual number may be much less than 1%). The size of the emacs binary, stripped, is also about 1% more with my code. The difference between the code you suggested and mine is mostly NILP(), though my test code optimizes away all tag bit checks if the compiler proves either argument is definitely not a bignum, or that the arguments have different tag bits. I'm also using __builtin_expect, something I think should be okay in this exceptionally hot single location.