From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.bugs Subject: Re: Serious performance issues with 1.9.0 Date: Fri, 24 Jul 2009 12:23:17 +0200 Message-ID: References: <200907151107.54800.martin@gkc.org.uk> <200907191456.47626.martin@gkc.org.uk> <200907201348.23213.martin@gkc.org.uk> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1248433458 22495 80.91.229.12 (24 Jul 2009 11:04:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jul 2009 11:04:18 +0000 (UTC) Cc: bug-guile@gnu.org, Ludovic =?utf-8?Q?Court=C3=A8s?= , Neil, Jerram To: Martin Ward Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Fri Jul 24 13:04:10 2009 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MUIZO-0002fL-7g for guile-bugs@m.gmane.org; Fri, 24 Jul 2009 13:04:10 +0200 Original-Received: from localhost ([127.0.0.1]:44659 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MUIZN-0007Dx-K5 for guile-bugs@m.gmane.org; Fri, 24 Jul 2009 07:04:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MUIXg-0006ef-HB for bug-guile@gnu.org; Fri, 24 Jul 2009 07:02:24 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MUIXb-0006cg-64 for bug-guile@gnu.org; Fri, 24 Jul 2009 07:02:23 -0400 Original-Received: from [199.232.76.173] (port=54129 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MUIXa-0006cW-GC for bug-guile@gnu.org; Fri, 24 Jul 2009 07:02:18 -0400 Original-Received: from a-sasl-quonix.sasl.smtp.pobox.com ([208.72.237.25]:44701 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MUIXV-0006Ec-SR; Fri, 24 Jul 2009 07:02:14 -0400 Original-Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 0BA06125BB; Fri, 24 Jul 2009 07:02:13 -0400 (EDT) Original-Received: from unquote (unknown [81.38.186.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id D3158125BA; Fri, 24 Jul 2009 07:02:08 -0400 (EDT) In-Reply-To: <200907201348.23213.martin@gkc.org.uk> (Martin Ward's message of "Mon, 20 Jul 2009 13:48:22 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-Pobox-Relay-ID: 70EB128E-7841-11DE-A478-F699A5B33865-02397024!a-sasl-quonix.pobox.com X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) X-BeenThere: bug-guile@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:4281 Archived-At: On Mon 20 Jul 2009 14:48, Martin Ward writes: > On Sunday 19 Jul 2009 23:03, Andy Wingo wrote: >> Discussed here: >> >> =C2=A0 http://article.gmane.org/gmane.lisp.guile.devel/8882 >> >> I'm working on a fix, hopefully within a couple of days. > > Great! Let me know when it is ready, and I'll put it through > its paces for you. Well! Your code brought to light three limitations in the current code, and two bugs. The first limitation was that before, we allocated all set! variables in a linear list within a function. Now they are allocated in boxes on the stack. I increased the number of possible stack variables from 255 to 64K, but that turned out not to be necessary, since your set! variables were often in ephemeral lexical scopes, so the local variable slots could be reused in different parts of the function. Then the first bug: sometimes the alpha-renamed variables from psyntax were not globally unique. The algorithm was, "variable stem + monotonically increasing integer". Obviously that doesn't necessarily work if the variable stem ended in an integer. I was aware of this, but somehow it hadn't bitten anyone until compiling your code. Now it is fixed. At this point I could compile ALL.scm. Then the second limitation: the default VM stack is too small, and we have no overflow handler to increase it. So I raised the default VM stack size. We'll lower it back down again, perhaps, once we implement overflow handlers. Then the second bug: ALL.scm compiled, and the first could prog_to_spec_TEST tests passed, but then I got an "invalid instruction" error. But the function that produced the error disassembled fine... then I noticed the function was around 70K bytes in length, close to another limit: that jumps are encoded in a 16-bit value. It didn't take too much more poking to find out that a forward jump of 64823 bytes was being interpreted as a backwards jump, because it's a signed 16-bit value. I added some more checks in the assembler to catch this at compile-time. Which brings us to now. ALL.scm doesn't compile any more because of that 16-bit limit, which is now caught correctly. I am afraid we will have to move to 32-bit words as Ludovic has suggested all along, because the proliferation of short and long addressing modes is getting too much. I guess that's the next thing on my plate, then... Regards, Andy --=20 http://wingolog.org/