Re: GETF Speedup?

Heh! Well AI Suggestions for “How to clear M1 memory cache” — Reboot the machine.

There are 3 levels of cache on the M1 ranging from ≈200KB for L1, up to ≈12 MB for L3. And honestly, the M1 architecture is probably obsolete at this time. So don’t bother too hard on M1 tests. 

But too, you have to consider why we are doing this in the first place? How often will the key-val store be searched?

In my case, I was constructing a Q&D version of SELF. And so the key-val pairs were short stubby little associations in each Object. Any one Object probably gets sporadically scanned, with (hopefully) a lot more useful work being accomplished between property scans.

In that case, use whatever data structure you want. It probably won’t make a measurable difference.



> On Oct 11, 2025, at 07:38, David McClain <[email protected]> wrote:
> 
> Maybe using an oscilloscope? Have the code trigger an I/O line at start and end, then flush cache and repeat. Use a storage oscilloscope to build up a composite trace of the on/off intervals?
> 
> 
> 
>> On Oct 11, 2025, at 07:35, David McClain <[email protected]> wrote:
>> 
>> So, I agree with the basic premise that any random search needs to be wholly from flushed cache, to make a valid measurement.
>> 
>> That means we can’t just run one query after another. We need to time each individual query, flush the cache with other activity or GC, and repeat.
>> 
>> How to measure such short time intervals, and build up a histogram history???
>> 
>> 
>>> On Oct 11, 2025, at 07:29, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
>>> 
>>> Yes, I might well be testing the M1 cache characteristics. I did think of that. But that’s also okay in my book. 
>>> 
>>> The question I posed to myself was, for small'ish property key-val pairs, which data structure is fastest? On M1 it turns out that GETF property lists win out for dimensions below 1_000. 
>>> 
>>> But I think you are making a deeper point here - that the test in the immediate aftermath of building the property list gives that list a cache advantage. Perhaps the list hasn’t been flushed to memory yet. And you might be correct.
>>> 
>>> So doing a “proper” test would be a bit more involved. I’d guess you build the list, stash it away, run a compile or two against some external Lisp source, then come back and query the speed of list traversal.
>>> 
>>> But then, after the first failed scan, the entire table would be back in cache again, and every subsequent query would win again...
>>> 
>>> My original notes from more than 10 years ago were based either on PowerPC or Intel architectures. And in those instances my notes showed that GETF was faster than GETHASH for dimensions below 100 key-val pairs.
>>> 
>>> 
>>> 
>>>> On Oct 11, 2025, at 07:23, Michał phoe Herda <[email protected]> wrote:
>>>> 
>>>> W dniu 2025-10-11 16:07, David McClain (as dbm at refined-audiometrics dot com) napisał(a):
>>>> 
>>>>>          (lst  (mapcan 'list keys vals))
>>>> Are you sure you are not measuring cache locality? MAPCAN #'LIST may effectively allocate conses of the whole plist next to one another in memory, where a CPU may recognize that it can optimize away pointer traversal and random memory access.
>>>> 
>>>> I'd rather go for a benchmark where the conses are shuffled across the whole memory, with some GCs in between for a good measure.
>>>> 
>>> 
>> 
>