From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp JIT Compiler Date: Sun, 19 Aug 2018 12:17:01 -0600 Message-ID: <87pnyeql0i.fsf@tromey.com> References: <87va8ej4o1.fsf@tromey.com> <87mutpiyz6.fsf@tromey.com> <701cd05f423e0c46595a3010f45414d0.squirrel@dancol.org> <520f536b5a603831c9a57a5f6f0978a2.squirrel@dancol.org> <83va8binu8.fsf@gnu.org> <87bma3i26m.fsf@tromey.com> <83in4aigs7.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1534702622 16676 195.159.176.226 (19 Aug 2018 18:17:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 19 Aug 2018 18:17:02 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) Cc: eggert@cs.ucla.edu, Eli Zaretskii , Tom Tromey , emacs-devel@gnu.org To: "Daniel Colascione" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 19 20:16:57 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 1frSG0-0004D2-Q7 for ged-emacs-devel@m.gmane.org; Sun, 19 Aug 2018 20:16:57 +0200 Original-Received: from localhost ([::1]:43746 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frSI7-00084e-5E for ged-emacs-devel@m.gmane.org; Sun, 19 Aug 2018 14:19:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frSH4-000835-VM for emacs-devel@gnu.org; Sun, 19 Aug 2018 14:18:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1frSH1-0004XZ-QX for emacs-devel@gnu.org; Sun, 19 Aug 2018 14:18:02 -0400 Original-Received: from gateway33.websitewelcome.com ([192.185.145.82]:43976) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1frSH1-0004Ve-JD for emacs-devel@gnu.org; Sun, 19 Aug 2018 14:17:59 -0400 Original-Received: from cm12.websitewelcome.com (cm12.websitewelcome.com [100.42.49.8]) by gateway33.websitewelcome.com (Postfix) with ESMTP id 25E0CB465 for ; Sun, 19 Aug 2018 13:17:04 -0500 (CDT) Original-Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id rSG8fWwO9SjJArSG8fDkaN; Sun, 19 Aug 2018 13:17:04 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=9bxuj9LGmnnybkB3gsQAufb+s9YHtRTmMYYKWrQb91g=; b=Xm43nQwV3M40d+8aYqOhHkmd3P Ar2P8VsHbtv7tBk0HNTyhMvtceEqv1fRYWcZo+7dJlwiU2RW0N2lqLeRQ3xMolXjv3dB406tSseW2 p47Hrp7AmeIF0eLJqO3x9vuBc; Original-Received: from 75-166-85-72.hlrn.qwest.net ([75.166.85.72]:42388 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1frSG7-002tzC-H9; Sun, 19 Aug 2018 13:17:03 -0500 X-Attribution: Tom In-Reply-To: (Daniel Colascione's message of "Thu, 16 Aug 2018 08:43:05 -0700") X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 75.166.85.72 X-Source-L: No X-Exim-ID: 1frSG7-002tzC-H9 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 75-166-85-72.hlrn.qwest.net (bapiya) [75.166.85.72]:42388 X-Source-Auth: tom+tromey.com X-Email-Count: 4 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 192.185.145.82 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:228694 Archived-At: >>>>> "Daniel" == Daniel Colascione writes: Daniel> I also strongly suspect (albeit without numbers ATM) that the standalone Daniel> approach will yield much better performance than one which involves a trip Daniel> through the filesystem and a compilation toolchain. A standalone system Daniel> lets us do tiered and profile-guided compilation in a way that a big batch Daniel> process really can't accommodate due to overheads. True, though it's worth noting that libjit doesn't really have optimization passes to speak of. Also things like deoptimization seem hard with libjit; there's no support for patching functions or on stack replacement or whatnot. libjit optimizations could be written. I haven't tried, so I don't know how hard it is in practice. I do have an incomplete branch where I'm changing the JIT calling convention to try to get better performance in the common case. This branch would also allow inlining (with a runtime check to ensure the callee hasn't changed). Going beyond this sort of thing (for instance Stefan sent me this very interesting paper about basic block versioning) probably requires a truly custom JIT from the bottom up. Daniel> Likewise, it'd be fantastic to compile regular expressions to DFAs and Daniel> then generate machine code for the DFAs. You can't go faster than that. I've been meaning to experiment with this using Stefan's lex.el. It seems to me that the bytecode compiler could open-code some common things like (looking-at "some constant"). One "simple" way to improve regexp matching right now would be to remove the self-modifying code and change the implementation to use token threading, like we did for the bytecode interpreter. Not nearly as good as a DFA but still a step forward. I think removing this self-modifying stuff is also useful if we ever want to introduce first-class regexp objects. Tom