Re: LW compiler optimizations

I find it somewhat interesting that vDSP uses strides throughout. No doubt makes it easier to deal with FFT varying strides in each iteration. But you might expect the pervasive use of strides to slow things down a bit. Stil, they exhibit very respectable performance.

So back to the original original posting about my surprise that the Lisp FFT was faster than my calling out to vDSP. Something must be amiss there. I can think of one area where I might be taking a speed hit on old vDSP calling code. I was working on old knowledge about the FLI and made overt copies of every array going across to C. 

So this exercise woke me up to the “new” capabifilities of the FLI where specialized arrays can be locked down and sent directly over to C and back. Maybe I need to comb through my ancient code and tease out all that data movement.

> On Jan 14, 2025, at 16:05, Yuri Davidovsky <[email protected]> wrote:
> 
> 
>> On 14 Jan 2025, at 23:37, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
>> 
>> These timings hint that they may be using some low-grade SIMD instructions. But I am thoroughly ignorant of the capabilities of the M1 architecture. Do they even have low-grade SIMD like the Intel MMX engine?
> 
> Quite similar to mmx actually, they use neon simd from the arm architecture, which is 128 bits wide. Rudimentary by modern standards in terms of bit width but can bring 2.5-3x increase in performance still. vDSP´s docs page states that it does use SIMD where possible.


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html