From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: On elisp running native Date: Fri, 27 Dec 2019 10:53:23 -0500 Message-ID: References: <838smzq9iz.fsf@gnu.org> <8336d6rfgy.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="60827"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 27 16:53:51 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 1ikrvy-000FgE-Bf for ged-emacs-devel@m.gmane.org; Fri, 27 Dec 2019 16:53:50 +0100 Original-Received: from localhost ([::1]:36624 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ikrvx-0004pj-4v for ged-emacs-devel@m.gmane.org; Fri, 27 Dec 2019 10:53:49 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56808) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ikrvk-0004pE-Fl for emacs-devel@gnu.org; Fri, 27 Dec 2019 10:53:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ikrvi-0007tl-VW for emacs-devel@gnu.org; Fri, 27 Dec 2019 10:53:36 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:15902) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ikrvg-0007oT-Bd; Fri, 27 Dec 2019 10:53:32 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 4D16382C1E; Fri, 27 Dec 2019 10:53:31 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CD5C181090; Fri, 27 Dec 2019 10:53:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1577462009; bh=0GQzwNqjtTc5Peffj2bhxUrz7755WH6s9NzBYdIr2YE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=ZQ/ga6Gh0sSCPKEMrcZevvHfVLm6cWbwHg9KSajOVvmDRjEx9MTqPvrI6rYgTnQc2 gjJdI69tik17p1QIIc4+ogGDXeXJ/D1g3Zdx7fQgB3crzAmwRmR7zOMMVPoqGJDOrQ J+IbQuq7tEztx+0SrVEw4L7JQh4FTq5MF0Gg0aa0A5KognwYB7oZBRb/yc15SKIC5r 7Y63LGfw5414g7hdJnOT4tU0yCXZIyZGFB8IYjoYsO6l37ZOkxNkVojLvvTp5iDOjz VmO7Ur7uLwwFw+HPBtNZSeqVPST9VVlp2qbVyBiuqJfW3Peu3Vv1iuUhxpB3zWxmaI T7IBUZWO3j68w== Original-Received: from pastel (104-222-126-118.cpe.teksavvy.com [104.222.126.118]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 88A541212FB; Fri, 27 Dec 2019 10:53:29 -0500 (EST) In-Reply-To: (Andrea Corallo's message of "Thu, 26 Dec 2019 22:10:56 +0000") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 132.204.25.50 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:243704 Archived-At: > What do think about the general idea of having a compiler able to native > compile elisp? > > What do you think about the proposed design (Lisp -> LAP -> LIMPLE -> > libgccjit -> elf)? I think the general design is quite sound, yes. > Do you see any weakness in some part of the design you would be > particularly worried about? - Beside the issue of portability/availability of libgccjit, there's also the issue of stability of libgccjit. More specifically, what is the probability that libgccjit will still exist more or less in the same form in 10 or 20 years? So far GCC's main entry point has been the command line, so we can expect that running `gcc` will still work 20 years from now. Similarly, LLVM's main entry point is an API that builds a kind of CFG representation of code, so we can expect that to still exist 20 years from now. But to the extent that libgccjit is not very widely used, there's a risk it will completely disappear or change radically, especially since we use it here in a way contrary to what its name ("...jit") suggests. - Going through the byte-compiler's LAP code is convenient but not ideal. Eventually, you'll want to circumvent bytecomp.el and write fresh new code to go from Lisp to LIMPLE without the detour through a stack machine (and probably not in a single step either). It's not a source of *worry*, tho. > Do you see in this a potential for having it up-stream in the future? Yes, tho it will take time. The main benefit of such a compiler is not to run existing Elisp code faster (99% of existing Elisp code runs fast enough that the user won't notice if it runs faster) but to make it practical to write *other* Elisp code which would otherwise be too slow. But for that to work well, you want the new compiler to be available "everywhere", rather than just on some platforms. So it will only start being useful when it works on GNU/Linux, macOS, Windows, ARM, RISC-V, x86, amd64, MIPS, younameit (AFAIK lbgccjit's CPU coverage is already good enough for that, so the main barrier here is the OS support), and when it's not just an option at compile-time but when it's included in all builds. So, first it will take time for the compiler to work in all these cases, then for the feature to be enabled by default, and then for code to start making actual use of it. Stefan