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: Preview: portable dumper Date: Fri, 2 Dec 2016 07:38:50 -0800 Message-ID: References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <8360n6ruzu.fsf@gnu.org> <834m2nplmb.fsf@gnu.org> <83inr2oje6.fsf@gnu.org> <83shq6mlt3.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1480693149 29278 195.159.176.226 (2 Dec 2016 15:39:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Dec 2016 15:39:09 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 Cc: emacs-devel@gnu.org To: Eli Zaretskii , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 02 16:39:05 2016 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 1cCpvU-0006ON-U8 for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2016 16:39:05 +0100 Original-Received: from localhost ([::1]:35183 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCpvX-0001k8-AR for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2016 10:39:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52937) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCpvQ-0001k1-Vx for emacs-devel@gnu.org; Fri, 02 Dec 2016 10:39:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCpvM-0002uk-UG for emacs-devel@gnu.org; Fri, 02 Dec 2016 10:39:00 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:49108) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cCpvM-0002ua-Kg; Fri, 02 Dec 2016 10:38:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=EmBMTh/J4KrE2tN4wh2jbct8iupj7/onliynO8E4oIQ=; b=Ddmuk4j6GMS8I6BTFJkaHrjbWe6kTp1q0oOI0avr8bCc6D51cVzEb8t6siM1KnnE1vr8i60VAJzHEMYxMmilXqtkA6y+O4rjCv06Afo7kfQJEdFYsyhmFAQNNaN/svTd36f9rUAT7sXrhkOAFy0M89B+nkjEylNHFUt+DC1C0p1j10l1Eu/APL6cYyrFHfBj6oQr0o1W3ACJr10nl0xVUlEubJa1uaope3S9HLlcy09r+AvqZpkSN0x3Rk6t8PuVhYURciAlmF9BimaVAZXg46ciB8nyHYRKaDkpwhSCf2GhxhnpOPJM7kKI356qW2j3b8HbS4SIcx0MrEoR06gv4w==; Original-Received: from c-73-140-245-253.hsd1.wa.comcast.net ([73.140.245.253] helo=[192.168.1.173]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cCpvK-0007GH-A1; Fri, 02 Dec 2016 07:38:54 -0800 In-Reply-To: <83shq6mlt3.fsf@gnu.org> 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:209927 Archived-At: On 12/02/2016 06:45 AM, Eli Zaretskii wrote: >> From: Stefan Monnier >> Cc: emacs-devel@gnu.org >> Date: Fri, 02 Dec 2016 08:04:46 -0500 >> >>> Granted, the proposed dumper is not very complicated. But it isn't >>> trivial either. So if we can achieve a similar effect by using the >>> "normal" loadup code, which is much simpler and doesn't really require >>> understanding anything new, I think it's more beneficial for the >>> project's future. >> >> Ken worked on speeding up the lread.c code, and it got to be >> significantly faster, but not fast enough. AFAIK it's got to the point >> where it's not clear exactly how to speed it up further. Not that it >> can't be done, but that it's not obvious how, so it's likely going to >> require some serious rethinking and maybe restructuring/rewrite of >> the code. >> >> Is it going to happen if we don't merge the pdumper? I'm not so sure. > > I'm willing to give that a chance. I don't see any reason to make the > decision today. > >> The main impetus behind speeding up lread.c is to replace unexec.c, so >> I agree with you that merging the pdumper might mean that speeding up >> lread.c will simply never happen. But I think there's also a very >> serious risk that even without the pdumper, speeding up lread.c will >> still never happen: I have no intention on working at speeding up >> lread.c, AFAICT Ken also gave up on it, anyone else? > > Judging by Ken's response, he didn't give up yet. > > In any case, it should be clear to anyone that code which isn't > written cannot be used. So a reality check will get us straight. > >> Personally, I think that maybe we should move in the other direction: >> keep lread.c for "source code" and generalize the pdumper code so it can >> also be used for the .elc files. > > You mean, move the byte compiler to C? Ideally, yes: one way, we'll compile with libgccjit or something. But that's a long way away. For now, nobody's talking about the byte compiler. Stefan's talking about the code that *reads* the byte compiler's output. Right now, this code is the normal lisp reader, but it doesn't have to be. > If not, I don't understand the idea: pdump wants a file in a very > specific format, because it doesn't really understand the entities it > reads. pdumper's loader is stupidly simple. It doesn't understand anything about what it's loading. That's what makes it fast. Stefan's idea is to make the elc format closer to the pdump format. Advantage: it'll be much faster that way. Disadvantage: elc files will be closely coupled to the precise Emacs builds that generated them.