sr (nobody.delete@this.nowhere.com) on September 11, 2021 1:36 am wrote:
> --- (---.delete@this.redheron.com) on September 8, 2021 2:28 pm wrote:
>
> > Finally I cannot figure out how Apple bypasses D- way prediction, but they don't seem to need
> > it -- at least even the most random stream of addresses (in terms of hitting different ways)
> > that I could generate never seemed to cause even a hiccup in terms of invalid way prediction.
> > I have a few hypotheses, but no strong leads, and no patents suggest an explanation.
> > On the I- side it's easier -- way info is stored in various appropriate places,
> > like, for example, the Next Fetch Predictor -- and this is described in patents.
>
> That' way L1-cache tags need to be in program address space. With physical tags it's impossible to do any
> kind of way prediction with tag bits but with linear address space you could use tag bits itself to do "way
> prediction". AMD is documented how they do it. It's a "way prediction" because it isn't traditional way prediction
> where first is compared predicted way and then rest - what they do is to make tags so short that they can
> compare all ways effectively. So way prediction newer missed, it's either L1 hit or miss.
>

I understand what you are saying. There are multiple ways in which this sort of thing can be done, ranging from placing a way table in the TLB (D2D cache) to using partial tag comparisons (which Apple definitely does for the L2, as in this patent: https://patents.google.com/patent/US10157137B1
to mapping packing of lines into the rows of a subarray.

What I have not established is any particular claim as to how Apple does it in the L1D, just that whatever they do, they manage to hide it from visible code. Standard partial tag comparison is a probabilistic thing so it should occasionally fail and generate a timing glitch. I never saw such -- but Apple have a very nice, lightweight, Replay+Speculative Scheduling mechanism, so with rare enough glitches, they can probably hide such a glitch.

Compare this to throughput based on address patterns, where you can, with carefully crafted patterns, very definitely see the falloff in throughput with different TLB access requirements, requests that all route to one half of the cache, requests separated by varying numbers of cache lines, and so on.