gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: possible dotimes enhancement


From: Paul F. Dietz
Subject: [Gcl-devel] Re: possible dotimes enhancement
Date: Thu, 31 Jul 2003 19:34:27 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Camm Maguire wrote:
Greetings!  I was just looking at how gcl compiles a matrix
multiplication today.  In short, once one makes sure all the
declarations are kicking in, it appears as if it can get as fast as
native C.

There does appear to be a curent inefficiency in our dotimes
definition, as compared with do and do*.  The existing definition is:

(defmacro dotimes ((var form &optional (val nil)) &rest body
                                                  &aux (temp (gensym)))
  `(do* ((,temp ,form) (,var 0 (1+ ,var)))
        ((>= ,var ,temp) ,val)
        ,@body))

If one declares the type of var, optimizations still do not kick in
because the gensym'd temp has no declared type.
I'm proposing the following:

(defmacro dotimes ((var form &optional (val nil)) &rest body
                                                  &aux (temp (gensym)) temp1 
temp2 temp3 temp4)
  `(do* ((,temp ,form) (,var 0 (1+ ,var)))
        ((>= ,var ,temp) ,val)
,(dolist (temp1 body temp4) (when (eq (car temp1) 'declare) (let ((temp2 (cadr temp1)))
                 (dolist (temp3 (cdr temp2))
                   (when (eq temp3 var)
                     (setq temp4 `(declare (,(car temp2) ,temp))))))))
        ,@body))

This basically will extend the user's possible declaration of var to
that of the integer evaluation of form stored in temp, as would appear
to make sense, as var has to count up to this value in any case.

With this enhancement in my preliminary testing, all loops of the form
'(dotimes (i form) (declare (fixnum i)) ...) have the counting variable
incrementation and comparison fully optimized, i.e. avoiding the
generic number_compare, etc.

So what do the lisp experts think?  Am I getting into trouble?


This goes wrong when FORM is negative:

   (dotimes (i (1- most-negative-fixnum) i)
     (declare (type fixnum i))
     (error "shouldn't happen"))
   ==> 0

You could test the count form for negativity first, then bind it to
another variable of the same type as the index variable.



Separately, at some point we have to figure out why the optimizer
cannot currently optimize

(declare (fixnum i)) (aref a (+ i 1))

but only

(let ((m 0)) (declare (fixnum m i)) (setq m (+ i 1)) (aref a m))

AREF requires each of its indices be a fixnum, so it's legal to
treat

  (aref a i j ... k)

as

  (aref (the fixnum i) (the fixnum j) ... (the fixnum k))

        Paul






reply via email to

[Prev in Thread] Current Thread [Next in Thread]