Add block lookup cache to optimize findBlock() #3160
Conversation
6fc5fe8 to
390e68a
Compare
Cache last found block to skip RB-tree lookup on consecutive accesses. Safe during re-entrance via direct pointer dereference (reads NULL when blocks temporarily zeroed, causing natural cache miss). Cache hit rates measured in real workloads: - Small program (qsort): 64.7% (249/136) - Large game ELF: 72.7% (35,392/13,302) - Large game PE+Wine: 85.3% (64,432/11,097) Wine workloads benefit most due to intensive allocation patterns. Converts 65-85% of O(log n) lookups to O(1) cache hits.
390e68a to
eb827df
Compare
|
Thnaks, interesting stats. Do you you think it could improve if there was 1 cache per blocks type? Also, would it be interesting to do that on Dynarec Blocks too? |
Good idea! I will do more stats on it. |
|
For "per-type block cahce", I ran a temporal clustering analysis on Large Windows game with Wine (petsitting) (46,518 block accesses) to measure how densely the three block types are used by TYPE DISTRIBUTION: The visualization above shows the temporal access pattern across all 46,518 accesses. The data reveals strong temporal clustering - only 2.39% of accesses involve switching between block types, meaning blocks of the same type are accessed consecutively 97.61% of the time. I analyzed the continuous sequences of each type and found: For this Wine gaming workload, I'm not sure if there will be a significant improvement in performance, since MAP64 dominates and programs typically access the same block type repeatedly before switching. How to Reproduce:
|
Implements a block cache in
findBlock()to avoid repeated RB-tree lookups when accessing the same memory block consecutively.Exploits both temporal locality (repeated access to same block) and spatial locality (newly created blocks are immediately used).
Real-world cache hit rates measured(same config as in issue #2511 but with the new version of box64):
Impact: Converts 65-85% of$O(log n)$ RB-tree lookups to $O(1)$ cache hits, reducing
findBlock()overhead in allocation-heavy workloads.side note:
Cache invalidated before
box_realloc()to prevent use-after-free whenp_blocksarray grows. Without this, cached pointer would reference freed memory after reallocation moves the array. Cache is repopulated after new block creation with valid pointer from new array location.