Re: LW compiler optimizations

So I see that the inner closure is calling Compiler Double-float Box on the computation. The allocations must be reflecting that across 5633 calls, which translates to 48 bytes per call.

So to see if I can get rid of boxing, I set up the SUM as a one-element array, specialized to double-float elements. And sure enough, that more than doubled the speed and cut the allocations down to a little over half the original number.

Oddly, when I reran my bench test, at the start, this time the mapping routine took twice as long as in my earlier bench tests. (very puzzling behavior) 

So now with the 1 element array SUM, I’m back to 124 μs/invocation on 5633 elements.

But the fact remains, if you want to avoid boxing, use a specialized array destination for the computed result.

> On Jan 13, 2025, at 07:13, David McClain <[email protected]> wrote:
> 
> I divided down the allocations to per-invocation costs. 
> 
> The worst offender in this regard is the implementation that MAP’s a closure across the pairs of elements in the dot-product. It takes a whopping 270 kB per buffer dot-product. 
> 
> And yet it is so simple. The closure should only be formed just once per invocation.
> 
> (defun fir-dotpr-map (fir vec &key (start2 0))
>   ;; 128 μs/invocation for 5633 element vectors
>   ;; 270,502 bytes/invocation
>   #F
>   (declare ((vector double-float *) fir vec)
>            (fixnum start2))
>   (let ((sum   0d0)
>         (v     (make-array (length fir)
>                            :element-type 'double-float
>                            :displaced-to vec
>                            :displaced-index-offset start2)))
>     (declare (double-float sum)
>              ((vector double-float *) v)
>              (dynamic-extent v))
>     (map nil (lambda (a b)
>                (declare (double-float a b))
>                (incf sum (* a b)))
>          fir v)
>     sum))
>