From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: Crashes in "C-h h" Date: Fri, 5 Jul 2019 07:07:48 +0000 Message-ID: References: <83y31hes6r.fsf@gnu.org> <83r279epwe.fsf@gnu.org> <09f72051-d740-9115-c6fd-c4344c749568@cs.ucla.edu> <83muhvd9nm.fsf@gnu.org> <9b78b85d-a3c8-761f-e500-d51d4a985fa8@cs.ucla.edu> <83k1cybk8c.fsf@gnu.org> <83ef36ar0p.fsf@gnu.org> <5e9b9214-4ccd-68a4-2016-7ac3ea8a06d9@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="31717"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 05 09:09:32 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hjILb-00085P-9X for ged-emacs-devel@m.gmane.org; Fri, 05 Jul 2019 09:09:31 +0200 Original-Received: from localhost ([::1]:50042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hjILZ-0002Fl-Te for ged-emacs-devel@m.gmane.org; Fri, 05 Jul 2019 03:09:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41222) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hjIKc-0002Fd-2Z for emacs-devel@gnu.org; Fri, 05 Jul 2019 03:08:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hjIKa-0005Lm-4l for emacs-devel@gnu.org; Fri, 05 Jul 2019 03:08:30 -0400 Original-Received: from mail-oi1-x241.google.com ([2607:f8b0:4864:20::241]:38044) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hjIKY-0005It-66 for emacs-devel@gnu.org; Fri, 05 Jul 2019 03:08:26 -0400 Original-Received: by mail-oi1-x241.google.com with SMTP id v186so6476875oie.5 for ; Fri, 05 Jul 2019 00:08:25 -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=tVf6NY2hjFlbNbZU1ZsRpXhNh15alFVHhCrYhSVXCAk=; b=Jxxku5ESC/eGWhhQxcv/3HSq5JTm9J/qrR5bEt2UJ5UI64qA7CO6xEa+1Hp28X4naP W3ArJuY29xrsXD71rzaR+Q1TdoTUaAFC9jTOU9Gf3fPkcThyoKVngEvPxD4HZkpYNu1a 8cWITWyUXvomJdrd4G4/5mIORz4rWuPrzoLo5QGvLN/vbDPE/ZRagpDL0570/q5XymM4 3dIPnk5wGcGxlQ5q+Q7zMFTc2P9czmjqn6xkFLGXgnTsvzgsF+8IdFn0tnOZJcXZn4UG XzbxRF+mODCa3SbIoKYTpslNoHa+S/wPNF2iHk6DxGq+M8oPwh+4wVInKQv8Cd7S2bdl XqUA== 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=tVf6NY2hjFlbNbZU1ZsRpXhNh15alFVHhCrYhSVXCAk=; b=WH5emz9OrnFxYQYFq5oTKVbnbFU4f6/rXnThV/MvlocK8CetP0gNwHN+EAqODoTkoK r6u6GtoGYYsME+tqIN8xf2DiVzl5CFbtvM9T8o0NEdJCWqWMSLEePHWayMaUXmlYXUdy LsFjHKnoLqGN/83q4I0HrVw0bgbmHHKp8hoh36zFfFV7nyzcNtVxPSd5RVVdjxUNwymg dKH8qmgexRVc4rFPUUyaLOGSBUDf6eb0hJWOV7eldFuyz+DHIMMDe/zbkpvwmQANzHdL J3wZihoBSJDPCWvb5frUJSjML9XjFLs3Vnz5xhMTHy+sn97xKbf5xZyVDmQElJR6pk8+ m3SQ== X-Gm-Message-State: APjAAAViSJKCFytIdQ3u8Vxeerq5QMrfsLSfdSalOTnbSzcm6YZHJuTN n2sRIfLAwlQ4SXwykd1EwNT2FOGZ2DKH5uvFzVttt7Bm X-Google-Smtp-Source: APXvYqzFzPNo6GpLN5U3GA//mnzQK0aC01ne8O/i9daa7afMZJQDJWYNnSpjQLWVnx4TMJfrYcLoj1QNBQzFOhcxWEE= X-Received: by 2002:aca:be88:: with SMTP id o130mr1169400oif.122.1562310504486; Fri, 05 Jul 2019 00:08:24 -0700 (PDT) In-Reply-To: <5e9b9214-4ccd-68a4-2016-7ac3ea8a06d9@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::241 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:238367 Archived-At: On Thu, Jul 4, 2019 at 11:04 PM Paul Eggert wrote: > Pip Cet wrote: > > > I'm seeing a much smaller slowdown with "perf stat": 12.3 cycles/loop > > rather than 11.7. > > It very much depends on the CPU. I got results all over the map when I used > different CPUs. Sometimes there wasn't that much difference, sometimes more than > what I mentioned. FIXNUMP+XFIXNUM was always slower than EQ+make_fixnum, though. I don't see how it can be any faster. The code generated by EQ+make_fixnum seems optimal to me, and the code for even an optimal version of FIXNUMP+XFIXNUM would have to sign-extend the INTMASK bits first. > >> You mean twice faster (~2m vs ~1m), right? > > > > "g" is 8 seconds slower than "noop", but "f" is 76 seconds slower. Oops, I should have said "again", here. > My calculations have "f" 85 not 76 seconds slower, which means FIXNUMP+XFIXNUM > was about 11x slower (10.972x times slower, to be absurdly precise). > > I'm seeing a single branch in "f", which is well-predicted as it > > alternates between being taken and not being taken. > > Maybe my CPU isn't using 2-bit branch prediction for this case, whereas yours is. Maybe. Looking at the assembler code next to "perf stat" output would be one way to find out (if you're running Linux). > > gcc needs to recognize (x-c) & mask == 0 as equivalent to > > (x & mask) == c (in the right conditions) and emit whichever variant > > is faster.) > > Yes, this is the GCC performance bug I reported about a year ago > . You came up with a GCC > patch which you labeled "WIP". Maybe it's time to get that patch out the door? I sent the patch to gcc-patches, got no response, and then my old computer broke, so part of the patch is now untestable. I get the impression the GCC folks barely even get around to important bug reports, so micro-optimization is probably a low priority. > > I think it would make most sense to introduce a macro for comparing a > > Lisp object to a C integer, which does the right thing even outside > > the fixnum range. Slower, ... > > All this talk about optimization, and now you want things to be *slower*? :-) I doubt it's actually going to be slower, since memory access to the data probably dominates whatever register operations we do. The important thing is not to have mispredicted branches... Anyway, is there any reason not to have an assert in make_fixnum to make sure the number fits?