|
From: | Paul Eggert |
Subject: | Re: Lisp_Marker size on 32bit systems |
Date: | Fri, 7 Sep 2018 20:04:52 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
Stefan Monnier wrote:
I think 32 byte objects aren't supposed to be much more likely to be aligned on 32 byte boundaries than on 32B + 16B.
True, I miscalculated. If the cache line size is 64 bytes and objects are allocated on 16-byte boundaries (the case now), the probability that a randomly-placed 24-byte marker (allocated as 32 bytes) will straddle into two cache lines is (2-1)/4, or 25%. Whereas if objects are allocated in 8-byte boundaries as you're suggesting, the probability that the same marker will straddle is (3-1)/8, which is still 25%. So for this particular case the straddling issue should be a wash.
Those perf-stats also show improved I$ performance, which isn't explained by your suggested explanation. Similarly, they show a reduced number of instructions.
Yes, it could well be that the 32-byte allocation is faster than the 24 partly due to some reason other than d-cache effects. Although there is a smaller percentage of cache misses in the 32-byte version, it could be that this is because the 32-byte version uses simpler code that would be faster even if the cache miss rate were the same.
[Prev in Thread] | Current Thread | [Next in Thread] |