Re: GETF Speedup?

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.
>> 
>