From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas Rottmann Newsgroups: gmane.lisp.guile.devel Subject: fixnum? VM primitive, increasing fixnum operation speed Date: Wed, 23 Mar 2011 03:19:32 +0100 Message-ID: <1300846773-19003-1-git-send-email-a.rottmann@gmx.at> NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1300847131 15422 80.91.229.12 (23 Mar 2011 02:25:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 23 Mar 2011 02:25:31 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 23 03:25:26 2011 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 1Q2DlG-0004FH-9F for guile-devel@m.gmane.org; Wed, 23 Mar 2011 03:25:26 +0100 Original-Received: from localhost ([127.0.0.1]:53130 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q2DlF-00026Z-KR for guile-devel@m.gmane.org; Tue, 22 Mar 2011 22:25:25 -0400 Original-Received: from [140.186.70.92] (port=42338 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q2DgL-0006oG-21 for guile-devel@gnu.org; Tue, 22 Mar 2011 22:20:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q2DgE-0006Yg-9w for guile-devel@gnu.org; Tue, 22 Mar 2011 22:20:20 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:47504) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Q2DgD-0006YU-UP for guile-devel@gnu.org; Tue, 22 Mar 2011 22:20:14 -0400 Original-Received: (qmail invoked by alias); 23 Mar 2011 02:20:11 -0000 Original-Received: from 83-215-154-5.hage.dyn.salzburg-online.at (EHLO nathot.lan) [83.215.154.5] by mail.gmx.net (mp065) with SMTP; 23 Mar 2011 03:20:11 +0100 X-Authenticated: #3102804 X-Provags-ID: V01U2FsdGVkX19P7fQOts5POUw4L9p8+NkZjPiQM1XkqxAgh68tb9 cdyGNYlI/L/kf7 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by nathot.lan (Postfix) with ESMTP id 0B7003A685 for ; Wed, 23 Mar 2011 03:20:11 +0100 (CET) Original-Received: from nathot.lan ([127.0.0.1]) by localhost (nathot.lan [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzwLbWe6SiLP for ; Wed, 23 Mar 2011 03:20:04 +0100 (CET) Original-Received: from delenn.lan (delenn.lan [192.168.3.11]) by nathot.lan (Postfix) with ESMTP id DA9CF3A68F for ; Wed, 23 Mar 2011 03:20:03 +0100 (CET) Original-Received: by delenn.lan (Postfix, from userid 1000) id BC70C2C00C1; Wed, 23 Mar 2011 03:20:03 +0100 (CET) X-Mailer: git-send-email 1.7.4.1 X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 213.165.64.23 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:11962 Archived-At: This is another piece of my attempt at getting more speed out of the `(rnrs arithmetic fixnums)' library. The idea is that this patch would be applied to master. I think, at least in the current form, it is not eligible for 2.0.x, as it messes up the VM opcode numbers, which breaks all .go files, IIUC. After this patch has been applied, the R6RS fixnums library can be adapted to use the new primitive. I have locally already tried this, and on top of the previous patch ("Take some lowhanging fruit to speed up R6RS fixnum operations"), this one speeds up the ZIP benchmark by another factor of 1.75, yielding a runtime of 15 seconds. The fxxor benchmark added by the previous patch gets a ~3x speed boost. Now, I'm still not entirely satisfied, but these two patches should cover the lowest hanging fruits without changing the semantics of the fixnum operations. For well-behaved programs, it would not be necessary to do the checks for fixnum-ness at all, neither for the arguments nor for the return value. This would in effect alias the fixnum operations to their non-fixnum counterparts, violating R6RS, which demands exceptions to be thrown if arguments or return values exceed fixnum range. I conjecture that this would give another noticable boost, as it would eliminate at least a procedure call and the `fixnum?' checks. I'd argue that deviating from R6RS in this area is not desirable; after all I think the intention of the R6RS fixnum library is to provide specialized operations so that implementations can provide fast-path versions of the more general procedures when it is known that fixnum range suffices -- the fact that fixnum arithmetic is actually *slower* than general arithmetic on Guile is not a given, but an artefact of the way they are currently implemented. Ideally (at least speed-wise), all of the fixnum operations should be VM primitives. I'm not sure if we have enough opcode space for that. It also raises the question of maintainablity (which probably can be kept in check with appropriate C preprocessor trickery), and how to deal with the exceptions these procedures are required to throw. As we probably don't want to tie the R6RS exception system directly into VM, I was thinking of using a fluid containing a procedure that does the actual exception throwing; that fluid could be set by some R6RS library. Well, this is getting quite long already, so I'll stop for now. I'm looking forward to any responses! ,,rotty