From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?iso-8859-1?Q?Juhani_Viher=C3=A4koski?= Newsgroups: gmane.lisp.guile.devel Subject: Re: Enormous benchmark speedup Date: Thu, 2 Jul 2009 18:49:38 +0300 (EEST) Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="657408-1089038300-1246549778=:13026" X-Trace: ger.gmane.org 1246549994 11749 80.91.229.12 (2 Jul 2009 15:53:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Jul 2009 15:53:14 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Jul 02 17:53:07 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 1MMOav-0002yE-FX for guile-devel@m.gmane.org; Thu, 02 Jul 2009 17:53:06 +0200 Original-Received: from localhost ([127.0.0.1]:50219 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMOat-0006GE-30 for guile-devel@m.gmane.org; Thu, 02 Jul 2009 11:53:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MMOYE-0005gG-9c for guile-devel@gnu.org; Thu, 02 Jul 2009 11:50:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MMOY9-0005fn-Jl for guile-devel@gnu.org; Thu, 02 Jul 2009 11:50:18 -0400 Original-Received: from [199.232.76.173] (port=40662 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMOY9-0005fk-Az for guile-devel@gnu.org; Thu, 02 Jul 2009 11:50:13 -0400 Original-Received: from mail.kapsi.fi ([217.30.184.167]:49716) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MMOY7-00023e-9b for guile-devel@gnu.org; Thu, 02 Jul 2009 11:50:13 -0400 Original-Received: from kapsi.fi ([217.30.184.161] helo=lakka.kapsi) by mail.kapsi.fi with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MMOXk-00019h-CV for guile-devel@gnu.org; Thu, 02 Jul 2009 18:49:48 +0300 Original-Received: from moonshine (helo=localhost) by lakka.kapsi with local-esmtp (Exim 4.69) (envelope-from ) id 1MMOXa-0005Yl-A4 for guile-devel@gnu.org; Thu, 02 Jul 2009 18:49:38 +0300 X-X-Sender: moonshine@lakka.kapsi In-Reply-To: X-SA-Exim-Connect-IP: 217.30.184.161 X-SA-Exim-Mail-From: moonshine@kapsi.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false X-detected-operating-system: by monty-python.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:8825 Archived-At: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --657408-1089038300-1246549778=:13026 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE > > With recent changes in guile vm there are lots on improvements on the > > Gambit benchmarks. > > Improvements compared to what? I should have been more concise.. I have run these benchmarks against=20 guile HEAD for some time (after I reported a few bugs, performance=20 regressions included, affecting the benchmark suite I have done this=20 every once in a while to get some additional test coverage) and now I had= =20 something to report. Guile I compared to is a git version before vector=20 instructions were added to VM. Guile is now a little bit slower=20 generally, but significantly faster in many real-world benchmarks using=20 vectors. > > but there are huge wins in testcases involving vectors offsetting > > this. >=20 > Oh, that's cool, but it feels like we're slightly cheating on these. > ;-) Well it seems to be a good cheat then :) > This is not tail-recursive (because of the nested `ack' call in the > `else' clause), which is why it can lead to a stack overflow. I understand that, but I reported this because interpreter (both 1.8.6 and= =20 1.9.0) run this test successfully but VM does not. Probably real-world=20 programs don't have so deep a recursion, although they might when run with= =20 complex data.. Thanks for your reply, Juhani Viher=C3=A4oski --657408-1089038300-1246549778=:13026--