Re: A slightly surprising and good thing
"Tim Bradshaw (as tfb at tfeb dot org)" <[email protected]>
| Newsgroups | gmane.lisp.lispworks.general |
|---|---|
| Message-ID | <[email protected]> |
On 24 Mar 2026, at 15:34, Yuri Davidovsky <[email protected]> wrote: > I am curious why SBCL is not faster here. [...] +1 cycle of overhead. It has been a very long time since you could say 'extra instruction means extra clock cycle or cycles': processors just are not anything like that. Looking at the code of a simpler version the SBCL inner loop is 7 instructions while the LW loop is 8. But one of those is an unconditional branch in the LW case and I'd assume it can treat that as if it wasn't there and in particular it quite possibly can unconditionally execute the instructions either side of it together if there are no dependencies which there are not in fact. Ah, but actually let me tell you the terrible truth: those inner loop sizes are for the vector-of-doubles version I'm testing my thing against. My thing doesn't have vectors of doubles, it has arrays of rank 2 (in this case) of doubles (this is the only general approach to the problem, bearing in mind that rank 0 arrays can exist and so the SOA objects need to support that). The last index is always a compile-time constant for a given slot within the macro, which likely helps. So it's doing rank 2 array access. There does seem to be a marginal-but-detectable difference in performance between the SOA and raw 1d-vector case but it's very small (really so small I'm not willing to thrash my machine for long enough to get a statistically meaningful result). --tim _______________________________________________ Lisp Hug - the mailing list for LispWorks users [email protected] http://www.lispworks.com/support/lisp-hug.html