Re: Performance assistance / advice

LW is obtaining more than one FLOP per clock as well, if my counts are right.

I can't see any obvious fused instructions in the assembly either SBCL or LW produces. However the number of instructions per clock should be very dependent on the number of execution units and dependencies between the instructions.  As an example from the LW disassembly

468        : #x1E6B096C : fmul.d         d12, d11, d11
472        : #x1E6D09AA : fmul.d         d10, d13, d13
476        : #x1E6E09C9 : fmul.d         d9, d14, d14

Those three instructions have no dependencies: if there are three floating-point execution units then they can potentially all be dispatched at once by a superscalar processor.  I don't know how many floating-point execution units the M1 has per core: it's very hard to find anything concrete about the design at all. But I am guessing 'more than one'.

(Based on very casual inspection SBCL's instructions look possibly worse than LW's in some cases, which makes me wonder if the M1 has register renaming (I expect it has everything)).

However mostly I am not worried: if the compiler is smart enough to turn source code that expresses a number of not-replicated operations into something better, then that is actually how many FLOPS you can expect, I think.  After all, what is actually going on in a modern processor is not really more closely related to the machine code than that machine code is to the source.  Computer people divide into three groups: programmers, compiler writers who try not to make it too obvious how much smarter they are than programmers, and hardware designers, who rightly regard the other two groups as little more than the amoebae we are.

--tim

> On 11 Mar 2025, at 17:15, Yuri Davidovsky (as work at disclosure dot ie) <[email protected]> wrote:
> 
> 
> 
>> On 11 Mar 2025, at 16:52, Tim Bradshaw (as tfb at tfeb dot org) <[email protected]> wrote:
>> 
>> I'm not sure if these rates are plausible or not: I think they probably are: The M1 seems to be clocked at 3.2GHz and assuming 4 cores the SBCL unsafe rate is 2.1 FLOP/cycle/core which, given it's a superscalar processor, is plausible.
> 
> Not 100% sure but that may look off. Getting multiples of the clock speed without vectorisation might be pointing to something strange going on. Now, there is a fused multiply add instruction on arm64 (a * b + c) that combines 2 operations into one, which in theory may give you the stated ~2x increase per cycle in sbcl if you have plenty of such operations, but you have more than 2x operations per cycle, evidently. There may be some other similar instructions that I am not aware of, or sbcl is doing some low key vectorisation.
> 
> Most likely there is some compiler optimisation going on, which may, or may not be what you want here (I understand that you wanted to measure purely scalar performance), in which case non vectorised fma is fine if that is what is happening.
> 
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> [email protected]
> http://www.lispworks.com/support/lisp-hug.html

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