From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Daniel Colascione" Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp JIT Compiler Date: Thu, 16 Aug 2018 08:43:05 -0700 Message-ID: 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;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1534435629 6280 195.159.176.226 (16 Aug 2018 16:07:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Aug 2018 16:07:09 +0000 (UTC) User-Agent: SquirrelMail/1.4.23 [SVN] Cc: emacs-devel@gnu.org, Tom Tromey , dancol@dancol.org, eggert@cs.ucla.edu To: "Eli Zaretskii" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 16 18:07:04 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 1fqKng-0001W5-8t for ged-emacs-devel@m.gmane.org; Thu, 16 Aug 2018 18:07:04 +0200 Original-Received: from localhost ([::1]:56619 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqKpm-0003sF-GG for ged-emacs-devel@m.gmane.org; Thu, 16 Aug 2018 12:09:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40969) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqKQh-0006TR-9r for emacs-devel@gnu.org; Thu, 16 Aug 2018 11:43:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fqKQg-0008H8-DP for emacs-devel@gnu.org; Thu, 16 Aug 2018 11:43:19 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:45576) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fqKQc-000885-T6; Thu, 16 Aug 2018 11:43:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=ZaC185V7uwh809xXCkaCNhCgcjpgHFcFImoG5DyXWAU=; b=bNsZ4hVarzGOOoANtgL7qVk0+cU9s8seGWtzVyRAnVRh9j2u6sBOQtenYjfjYEyUNjSujZtUjqHHROEGUEegJwi3V0GYWKzJBvpKuFVpvd4dNCi7dOXG5Ji6/+ad8NvJg4o5+q2fxH+tluWqjWSVSwFz0+AojX56dFeV506zdyx+QXRPzxGpnF38a9BlasZlaQ5C+vcmVvzOl7PnMdDkN+x1hMTzJuHahdgbFtq9xNQV4RcXw9BGYzxKoPx4uYWKP10EXRutCd+IWl618jdBKKiwPIaNkyXQSVxZ8vebA+t7qck+z6We1HOLVyNxzGCNfLbhorZAklQq0+ErG7swgQ==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fqKQT-0003IJ-F6; Thu, 16 Aug 2018 08:43:05 -0700 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Thu, 16 Aug 2018 08:43:05 -0700 In-Reply-To: <83in4aigs7.fsf@gnu.org> X-Priority: 3 (Normal) Importance: Normal X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:228597 Archived-At: >> From: Tom Tromey >> Cc: Paul Eggert , dancol@dancol.org, >> tom@tromey.com, emacs-devel@gnu.org >> Date: Wed, 15 Aug 2018 18:29:37 -0600 >> >> That said I don't think it is a very important issue, I think primarily >> because interested users can port the JIT as needed. > > Only if they are _very_ interested, and have the knowledge/talent to > do that. It only takes one such person though. >> Eli> That doesn't mean we want to have predictably bad performance, but >> it >> Eli> does mean that we should choose our JIT library so that it doesn't >> Eli> suffer from such issues. >> >> There is no JIT library that supports everything. > > OK, let me rephrase: we should choose our JIT library so that it > suffers as little as possible from such issues. Right. And I think a standalone library is less likely to suffer from these issues than one that requires a full toolchain. It's easier to port back-end machine-code generation to an architecture than it is to port all of binutils. I also strongly suspect (albeit without numbers ATM) that the standalone approach will yield much better performance than one which involves a trip through the filesystem and a compilation toolchain. A standalone system lets us do tiered and profile-guided compilation in a way that a big batch process really can't accommodate due to overheads. I think it's also really important to emphasize the "IT" aspect of the JIT system. That is, there are tons of cases where it would be a huge help to generate specialized code (e.g., for parsing) and compile it on-the-fly. Imagine we have decent elisp parsers for languages A and B, but we (in some distant and glittering future) have robust multi-mode support and want to parse the language (A|B) in the buffer. Wouldn't it be nice to just synthesize A|B into some code and compile that straight to machine code? Likewise, it'd be fantastic to compile regular expressions to DFAs and then generate machine code for the DFAs. You can't go faster than that. All of these use cases need a level of dynamism that I'm afraid we wouldn't be able to get with good performance via a toolchain-based system.