From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: SRFI-1 in Scheme Date: Wed, 14 Jul 2010 00:09:39 +0200 Message-ID: <87hbk3uj8c.fsf@gnu.org> References: <8739vocnr0.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1279059001 4859 80.91.229.12 (13 Jul 2010 22:10:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Jul 2010 22:10:01 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Jul 14 00:10:00 2010 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.69) (envelope-from ) id 1OYnfq-0006hx-D9 for guile-devel@m.gmane.org; Wed, 14 Jul 2010 00:09:58 +0200 Original-Received: from localhost ([127.0.0.1]:36530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYnfp-0004CU-N2 for guile-devel@m.gmane.org; Tue, 13 Jul 2010 18:09:57 -0400 Original-Received: from [140.186.70.92] (port=59911 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYnfl-0004By-Av for guile-devel@gnu.org; Tue, 13 Jul 2010 18:09:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYnfi-0000YW-TX for guile-devel@gnu.org; Tue, 13 Jul 2010 18:09:53 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:38947) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYnfi-0000YJ-O8 for guile-devel@gnu.org; Tue, 13 Jul 2010 18:09:50 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OYnfg-0006ei-1Y for guile-devel@gnu.org; Wed, 14 Jul 2010 00:09:48 +0200 Original-Received: from acces.bordeaux.inria.fr ([193.50.110.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Jul 2010 00:09:48 +0200 Original-Received: from ludo by acces.bordeaux.inria.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Jul 2010 00:09:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 41 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: acces.bordeaux.inria.fr X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 26 Messidor an 218 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:XNzHlqmTp5TZcVlHL6F4/foax+w= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:10659 Archived-At: Hey! Andy Wingo writes: > On Tue 13 Jul 2010 00:57, ludo@gnu.org (Ludovic Courtès) writes: > >> The attached patch is a first stab at re-implementing SRFI-1 in >> Scheme. >> >> IOW, with the debug engine (currently the default) and for large lists >> ‘fold’ in Scheme is ~9% slower than in C; for small lists it’s ~17% >> slower. >> >> With the regular engine, Scheme is ~2% faster for large lists and still >> ~5% slower for small lists. >> >> I’m tempted to put this in > > Cool, looks good to me. Just to make sure, did you read the figures right? With the debug engine, the slowdown is noticeable. >> and then make the regular engine the default unless ‘--debug’ is >> specified. > > I would prefer to keep the debug VM as the default. AFAICS the only difference between the two engine is VM_USE_HOOKS. Hooks are only used in (system vm coverage) at this point, so we don’t lose much by disabling them. Am I overlooking something? > At the very least, one should be able to switch VMs. You mean switch VMs for the code being executed? (For code to be executed than can already be done using ‘vm-apply’.) Thanks, Ludo’.