Re: A mystery with slot access in LW

I think that’s a good theory. I’m not aware of a method to guarantee a process runs on a P core, though there is one for E cores and may improve your chances of getting a P core if you “suggest” more of your non-LW processes should get E cores (while also bumping up the priority of LW):

https://eclecticlight.co/2024/12/17/tune-for-performance-core-types/

NB: this isn’t from personal experience; I’m still doing all my development work on a 2019 Mac Pro. Lots of cores, all equal :-)

> On Apr 27, 2026, at 11:33 AM, Tim Bradshaw (as tfb at tfeb dot org) <[email protected]> wrote:
> 
> On 27 Apr 2026, at 13:24, Yuri Davidovsky (as work at disclosure dot ie) <[email protected]> wrote:
>> 
>> 
>> This type of inconsistency might not be that complicated, it seems like you are only running 10^8 iterations, which is not enough to warm the CPU up with such a small code body. Try running a gc pass right before the benchmark, and optionally increase the number of iterations in the test to a billion, or so, if anything, it should reduce the variance between the tests significantly.
> 
> Again: this is not my first rodeo.
> 
> That number of iterations is plenty, in fact, especially as the machine has just been doing a bunch of other work when this case runs.
> 
> I'm also not redefining classes: I have a bunch of classes which differ only in things like type specification.
> 
> However I think I've now worked out what must be happening.  Here are a bunch of successive values from the slot-value timing function:
> 
> 4.12E-9
> 4.125E-9
> 4.16E-9
> 1.777E-8
> 1.7925E-8
> 1.791E-8
> 1.7795E-8
> 4.095E-9
> 4.095E-9
> ...
> 4.1E-9
> 1.789E-8
> 1.7915E-8
> 1.7935E-8
> 4.075E-9
> ...
> 
> You can see pretty clearly that it has two states: a ~4E-9s state and a ~1.8E-8s state.  And it transitions between them.
> 
> Well, the M1 has fast cores and slow cores.  My guess is that something, somewhere is deciding that LW (or this LW thread) belongs on a slow core instead of a fast one.
> 
> I've never seen that happen before: whenever I have things which actually want lots of CPU time, the system seems to work that out and keep them on a fast core.  But perhaps there are lots of other things which want a fast core (there aren't that I can see), or more likely the machine has been up long enough and the scheduler has become senile.  I suspect the latter, but I don't know.
> 
> I still don't understand why the *other* parts of the tests don't also flip (for instance the raw fixnum increment test never moves between two states like this, neither I think do the array ones).
> 
> --tim
> 
> 
> 
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> [email protected]
> http://www.lispworks.com/support/lisp-hug.html