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: [r6rs-discuss] Implementors' intentions concerning R6RS Date: Mon, 12 Nov 2007 20:29:12 +0000 Message-ID: <87ir475ht3.fsf@ossau.uklinux.net> References: <818B5317-4F09-46F3-9376-43292CEB3C16@iro.umontreal.ca> <47229C5E.8070406@emf.net> <87640rm7ec.fsf@ossau.uklinux.net> <87hckbkpho.fsf@ossau.uklinux.net> <87d4uykkes.fsf@laas.fr> <87ejfd7fnq.fsf@ossau.uklinux.net> <877il57wyt.fsf@laas.fr> <2bc5f8210710300801o6de398aeg968bcb73bb0cc5e@mail.gmail.com> <87zlxzmnqp.fsf@laas.fr> <87d4un6nv0.fsf@ossau.uklinux.net> <87sl3c6bt6.fsf@chbouib.org> 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 1194899384 18706 80.91.229.12 (12 Nov 2007 20:29:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Nov 2007 20:29:44 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Nov 12 21:29:48 2007 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 1Irfuj-0007Zz-CJ for guile-devel@m.gmane.org; Mon, 12 Nov 2007 21:29:45 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IrfuW-0007fJ-VO for guile-devel@m.gmane.org; Mon, 12 Nov 2007 15:29:32 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IrfuR-0007du-MK for guile-devel@gnu.org; Mon, 12 Nov 2007 15:29:27 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IrfuP-0007bA-Kv for guile-devel@gnu.org; Mon, 12 Nov 2007 15:29:26 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IrfuP-0007ay-G4 for guile-devel@gnu.org; Mon, 12 Nov 2007 15:29:25 -0500 Original-Received: from mail3.uklinux.net ([80.84.72.33]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IrfuI-0007ag-Hw; Mon, 12 Nov 2007 15:29:18 -0500 Original-Received: from arudy (host86-145-183-175.range86-145.btcentralplus.com [86.145.183.175]) by mail3.uklinux.net (Postfix) with ESMTP id 3450B1F6C35; Mon, 12 Nov 2007 20:29:14 +0000 (GMT) Original-Received: from laruns (unknown [192.168.0.10]) by arudy (Postfix) with ESMTP id 4E05E38009; Mon, 12 Nov 2007 20:29:13 +0000 (GMT) In-Reply-To: <87sl3c6bt6.fsf@chbouib.org> (Ludovic =?iso-8859-1?Q?Court=E8?= =?iso-8859-1?Q?s's?= message of "Sun, 11 Nov 2007 16:28:53 +0100") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: 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:6892 Archived-At: ludo@gnu.org (Ludovic Court=E8s) writes: > Hi, > > Neil Jerram writes: > >> I think I understand the point here, and it seems to me that this is >> an improvement for the developer, not for the end user; and IMO not a >> significant one (because it's pretty trivial to write a smob mark >> function). It also implies a performance cost, from scanning regions >> of SMOB memory that Guile currently knows cannot contain heap >> pointers. > > It really isn't that clear what performance impact libgc's pervasive > scanning has. Fair enough, let's wait and see what further investigation reveals. >>> * Rewrite the interpreter in Scheme (or a subset thereof), with a >>> tiny Scheme-to-C compiler. That could be done in such a way that we >>> could re-use, e.g., the memoization and unmemoization code that >>> already exists in the first step. >> >> Interesting. Do you think that that would be a lot faster than the C >> code we have now? > > Note that whether it's implemented by hand in C or compiled to C doesn't > make a significant difference. The main optimizations I have in mind > are the following: These sound really interesting! Do we need to wait for a rewrite of the core interpreter, though, or could we try doing this in the current code? > * heap-allocation-free closure invocations, which can be achieved by > storing a closure's arguments into a stack-allocated C array or, > even better, in registers (of course, invoking closures with rest > arguments would still require allocating an argument list); > > * O(1) ILOC lookup, compared to the current O(N * M) algorithm, where > N is the frame number and M the position of the variable within that > frame's environment; Are you sure the current algorithm is O(N*M)? I would have said O(N+M). > * no C function call overhead for tail(-recursive) calls. I thought that was mostly achieved already, by extensive use of gotos. But I guess there must be important cases that I've not noticed. Regards, Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel