From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: srfi-18 and the vm Date: Sun, 31 May 2009 00:07:14 +0100 Message-ID: <87d49qrxzx.fsf@arudy.ossau.uklinux.net> References: <878wko16zz.fsf@arudy.ossau.uklinux.net> <87r5yfxysa.fsf@gnu.org> <87eiueegq3.fsf@gnu.org> <87tz386e2n.fsf@arudy.ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1243724856 21085 80.91.229.12 (30 May 2009 23:07:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 May 2009 23:07:36 +0000 (UTC) Cc: Ludovic =?iso-8859-1?Q?Court=E8s?= , guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun May 31 01:07:33 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MAXeE-0007LC-Ur for guile-devel@m.gmane.org; Sun, 31 May 2009 01:07:31 +0200 Original-Received: from localhost ([127.0.0.1]:58653 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MAXeD-00038B-UI for guile-devel@m.gmane.org; Sat, 30 May 2009 19:07:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MAXeB-00037q-0R for guile-devel@gnu.org; Sat, 30 May 2009 19:07:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MAXe5-000373-FM for guile-devel@gnu.org; Sat, 30 May 2009 19:07:25 -0400 Original-Received: from [199.232.76.173] (port=36319 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MAXe5-000370-BV for guile-devel@gnu.org; Sat, 30 May 2009 19:07:21 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]:55316) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MAXe0-00066i-SE; Sat, 30 May 2009 19:07:17 -0400 Original-Received: from arudy (host86-152-99-133.range86-152.btcentralplus.com [86.152.99.133]) by mail3.uklinux.net (Postfix) with ESMTP id C4DAD1F9CED; Sun, 31 May 2009 00:07:15 +0100 (BST) Original-Received: from arudy.ossau.uklinux.net (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id 2A54938013; Sun, 31 May 2009 00:07:15 +0100 (BST) In-Reply-To: (Andy Wingo's message of "Fri\, 29 May 2009 11\:55\:25 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8568 Archived-At: Andy Wingo writes: > Hi Neil, > > On Mon 25 May 2009 23:57, Neil Jerram writes: > >> ludo@gnu.org (Ludovic Court=E8s) writes: >> >>> Andy Wingo writes: >>> >>>> For loading uncompiled scripts, things will be slower, unless your >>>> modules #:use-syntax some other transformer. I don't know where the >>>> tradeoff is between the increased expansion speed due to compilation a= nd >>>> slowdown due to a complete codewalk, but it's certainly there. >>> >>> Yes. Likewise, it may be reasonable to assume from now on that most of >>> the code will be compiled. For instance, an uncompiled script may just >>> be a small code snipped that uses mostly compiled code. >> >> It seems to me that once we have a completely working compiler, we >> need to ask if there are any circumstances left where it is better to >> use the current interpreter instead. > > In the short term (within the next year or so), I would imagine that > ceval/deval would be faster than an eval written in Scheme -- though I > do not know. I wasn't thinking of an eval written in Scheme. I was assuming the other option that you mention below, i.e. eval becomes compile on the fly followed by VM execution. > On the other hand, an eval written in Scheme would allow for > tail-recursive calls between the evaluator and the VM. > > Another option, besides an eval in Scheme, is replacing the evaluator > with the compiler. One could compile on the fly and run the compiled > code from memory, or cache to the filesystem, either alongside the .scm > files or in a ~/.guile-comp-cache/ or something. > > But compilation does take some time. I guess this is the key point. Even when the compiler has itself been compiled? So would it be correct to say, based on your performance observations so far, that the time needed to compile and then VM-execute a piece of code is greater than the time needed to interpret the same piece of code? In other words, that ahead-of-time compilation is helpful, performance-wise, but that just-in-time compilation is net negative? (Perhaps that is a ridiculous question even to ask... It may be well known that just-in-time compilation is always net negative if you only consider one execution of the code concerned. I'm afraid I'm not familiar enough with the CS background on this.) > It seems clear we still need an eval in C, at least to bootstrap Guile. Yes, good point, I had forgotten that! >> Do we already have performance measurements, and are those recorded / >> summarized somewhere? > > We don't have very systematic ones. I was just running some of the > feeley benchmarks again, and it looked to me that the VM's speed is > about 3 or 4 times the speed of ceval in 1.9, but I should test with > benchmarks that run for only 1s or so, and measure compilation time, and > test against 1.8 too. So, extremely roughly, that would mean that just-in-time compilation could only be net-zero or net-positive if the complexity of the compilation code was less than 3 or 4 times the complexity of the code being compiled. Which for a short piece of code is unlikely. >>>> OTOH I would suspect that we can implement some kind of just-in-time >>>> compilation -- essentially for each use-modules we can check to see if >>>> the module is compiled, and if not just compile it then and there. It >>>> would be a little slow the first time, but after that it would load mu= ch >>>> faster, even faster than before. Python does this. We could add a guile >>>> --no-comp option to disable it. >>> >>> I don't like this idea because it implies implicitly letting Guile >>> fiddle with the user's file system. >> >> I don't see why that should be. Isn't it possible to read a .scm >> file, compile its contents, and hold the compiled programs in memory? > > Yes, compile-and-load, from (system base compile). But you have to redo > the compilation the next time the file is loaded, of course. > > Incidentally, ikarus had a similar discussion recently: > > http://thread.gmane.org/gmane.lisp.scheme.ikarus.user/723 > http://thread.gmane.org/gmane.lisp.scheme.ikarus.user/745 I see; good references - there's no need for us to have the same conversation again! I think I agree with Aziz's conclusion - i.e. "auto-caching" should be disabled by default. The thread suggested to me that Ikarus has to compile the code that it reads before it can execute it; i.e. that it doesn't retain an interpretation option. Is that correct? If so, Guile might reasonably make slightly different decisions - e.g. to interpret a module when using it for the first time, and also to start compiling it on another thread, with the module's procedures being replaced one-by-one by VM programs as the compilation progresses. Regards, Neil