unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Andreas Rottmann <a.rottmann@gmx.at>
To: ludo@gnu.org (Ludovic Courtès)
Cc: guile-devel@gnu.org
Subject: Re: [PATCH] Take some lowhanging fruit to speed up R6RS fixnum operations
Date: Fri, 25 Mar 2011 00:42:44 +0100	[thread overview]
Message-ID: <87zkokrsp7.fsf@vir.lan> (raw)
In-Reply-To: <87hbas427n.fsf@gnu.org> ("Ludovic Courtès"'s message of "Thu, 24 Mar 2011 22:51:08 +0100")

ludo@gnu.org (Ludovic Courtès) writes:

> Hi Andreas,
>
> I’m all for your suggestion.
>
> Andreas Rottmann <a.rottmann@gmx.at> writes:
>
>> +  (define-syntax define-fxop*
>> +    (syntax-rules ()
>> +      ((_ name op)
>> +       (define name
>> +	 (case-lambda
>> +	   ((x y)
>> +	    (assert-fixnum x y)
>> +	    (op x y))
>> +	   (args
>> +	    (assert-fixnums args)
>> +	    (apply op args)))))))
>> +
>> +  (define-fxop* fx=? =)
>
> How about making something like this (untested):
>
>   (define-syntax define-fxop*
>     (syntax-rules ()
>       ((_ name op)
>        (define-syntax name
>          (lambda (s)
>            (syntax-case s ()
>              ((_ x y)
>               #'(begin
>                   (assert-fixnum x y)
>                   (op x y)))
>              ((_ args ...)
>               #'(apply op args))
>              (_ #'op)))))))
>
> This way, there’d be no procedure call involved and ‘=’, ‘+’, etc. would
> use the corresponding instruction in the base case.
>
That's an excellent idea, and would probably boost performance quite a
bit.  However, there's still the issue that the non-two-args cases don't
throw the exceptions required by R6RS.  Upon trying to interpret the
R6RS in a way that would lift that requirement, I still see no way to do
so in the general case, due to the following quite explicit language:

  Fixnum operations perform integer arithmetic on their fixnum
  arguments, but raise an exception with condition type
  &implementation-restriction if the result is not a fixnum.

So even if checking the arguments seems to be not explicitly required
(but might be implictly intended -- "fixnum arguments"), the result must
definitly be a fixnum, or the mentioned exception be thrown.

So for the sake of efficiency, while heeding what is explictly required,
I propose the following:

- Alias all fixnum operations that yield non-fixnums (e.g. fx<?, fx>?,
  ...) with the corresponding non-fixnum procedures.  IMHO, that seems
  to be within bounds wrt. R6RS; Section 5.4 "Argument checking"
  says:

  The implementation must check that the restrictions in the
  specification are indeed met, to the extent that it is reasonable,
  possible, and necessary to allow the specified operation to complete
  successfully.  

  One might argue that it is not reasonable (for efficiency reasons
  related to the way Guile is currently implemented) and certainly not
  necessary to check the arguments for fixnum-ness in these procedures.

- Otherwise, do the macro trick as above, but fall back on a procedure
  like in SRFI-9's `define-inlinable' for the non-binary case.

Thoughts?

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>



  reply	other threads:[~2011-03-24 23:42 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-22 23:20 Take some lowhanging fruit to speed up R6RS fixnum operations Andreas Rottmann
2011-03-22 23:20 ` [PATCH] " Andreas Rottmann
2011-03-24 21:51   ` Ludovic Courtès
2011-03-24 23:42     ` Andreas Rottmann [this message]
2011-03-25 12:16       ` Andreas Rottmann
2011-03-27 15:19         ` Ludovic Courtès
2011-03-27 22:20           ` Andreas Rottmann
2011-03-29 11:05 ` Andy Wingo
2011-03-30  1:37   ` Andreas Rottmann
2011-03-30 10:31   ` Andreas Rottmann
2011-03-30 10:58   ` Andreas Rottmann
2011-04-02 17:42     ` R6RS fixnum arithmetic optimizations Andreas Rottmann
2011-04-02 17:42       ` [PATCH 1/3] Add a few benchmarks for R6RS fixnum arithmetic Andreas Rottmann
2011-04-02 17:42       ` [PATCH 2/3] Several optimizations " Andreas Rottmann
2011-04-02 17:42       ` [PATCH 3/3] Add `fixnum?' VM primitive Andreas Rottmann
2011-04-04 21:53         ` Andy Wingo
2011-04-05  0:14           ` Andreas Rottmann
2011-04-06 12:42             ` define-inlinable Ludovic Courtès
2011-04-06 21:30               ` define-inlinable Andreas Rottmann
2011-04-06 22:24                 ` define-inlinable Ludovic Courtès
2011-04-11 16:56                   ` define-inlinable Andy Wingo
2011-04-11 20:01                     ` define-inlinable Ludovic Courtès
2011-04-11 21:05                       ` define-inlinable Andy Wingo
2011-04-11 22:11                         ` define-inlinable Andreas Rottmann
2011-04-07 15:57             ` [PATCH 3/3] Add `fixnum?' VM primitive Ludovic Courtès
2011-04-04 21:28     ` Take some lowhanging fruit to speed up R6RS fixnum operations Andy Wingo
2011-04-04 22:00       ` Andreas Rottmann
2011-04-04 22:12         ` Andy Wingo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zkokrsp7.fsf@vir.lan \
    --to=a.rottmann@gmx.at \
    --cc=guile-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).