Re: LW compiler optimizations

Martin Simmons <[email protected]>
Newsgroups gmane.lisp.lispworks.general
Message-ID <[email protected]>
The :explain :boxing declaration will tell you about the boxing.  In most
cases when using the LispWorks IDE, you can then move the cursor to the
explain message in the Output and use Ctrl-x Comma ("Edit Recognized Source")
or "Find Source" from the context menu to find which form is boxing.

Unfortunately, that doesn't work if the form is generated by a macro like your
def-bfly.  You have to macroexpand that in-place and then compile the expanded
defun to see the location.

-- 
Martin Simmons
LispWorks Ltd
http://www.lispworks.com/



>>>>> On Sun, 12 Jan 2025 14:23:48 -0500, Paul Werkowski (as pw at snoopy dot qozzy dot com) said:
> 
> So,  it was over a month ago that I started this thread as I began 
> hunting down the source of heap allocations from a function that should 
> have none. After flailing around and getting nowhere, I FOUND IT!!
> 
> DBM's expression of amazement at LW's compiler's efficiency motivated me 
> to dust off my 2017 implementation of the FFT, ported from an initial 
> implementation (in 2002) using cmucl, to confirm my belief that no 
> boxing of floats was occurring. (declare (:explain :boxing)) did so 
> confirm, so what was going on?
> 
> I am embarrassed to say it was an error of omission of an important type 
> declaration, among several others there, that was responsible for 
> allocating 280 bytes per call where it should have been zero. 
> Apparently, at least for me, it is hard to find that which is not there.
> 
> The function of interest is the computational part of the Fast Fourier 
> Transform 
> (https://www.cs.cmu.edu/afs/andrew/scs/cs/15-463/2001/pub/www/notes/fourier/fourier.pdf) 
> called a Butterfly. Here it is in cl macro form;
> 
> (defmacro def-bfly (name ftype)
>    "Define a function for FFT Butterfly: ftype is float type"
>    `(defun ,name (V x y W)
>       (declare (type (integer 0 ) x y)
>                (type (complex ,ftype) W)
>                (type (simple-array (complex ,ftype)) V)
>                (optimize (float 0)(safety 0)) ; !!!!
>                (:explain :boxing))
>       (let* ((xc (aref V x))
>              (yc (aref V y))
>              (u (* yc W))
>              (b (- xc u))
>              (a (+ xc u)))
>         (setf (aref V x) a
>               (aref V y) b))
>       (values)))
> 
> to be used like this;
> 
> (def-bfly bfly-df double-float)
> 
> The missing declaration for W was the culprit. W is of the form (cis (/ 
> PI L)) where L is from the sequence 1 2 4 8 16 ... (log (length V) 2).
> 
> So, using declarations and optimization is a bit tricky. The only way to 
> be sure is disassembly of the compiled function and look for hints such 
> as seeing things like COMPILER::RAW-FAST-BOX-COMPLEX-FROM-RAW-DOUBLES in 
> the disassembly. The disassembly for the compiled butterfly function 
> (attached) is a thing of beauty.
> 
> 

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.