anon (anon.delete@this.anon.com) on January 21, 2014 1:18 am wrote:
> Nicolas Capens (nicolas.capens.delete@this.gmail.com) on January 20, 2014 2:49 pm wrote:
> > anon (anon.delete@this.anon.com) on January 20, 2014 1:19 am wrote:
> > > If this is still not enough, I would say something which is much better thought-out in terms of
> > > indexing and invalidation would be superior to this L0 idea, e.g., Intel's "signature buffer".
> > >
> > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.78.601&rep=rep1&type=pdf
> >
> > How is that superior? It's the exact same idea!
>
> It is a better idea than the L0, because it has much better indexing
> and invalidation in my opinion.

Better how? And how does it achieve that? Without any explanation it's just a hollow claim.

> > Note that I'm not claiming KNL to have an L0 cache as described at all. I'm just proposing
> > it as one possible way it may not require two L1 load ports.
>
> You said it was the best possible way. That it was more power
> efficient, that complexity would not be an issue, etc etc.

No, I said it's the best explanation for all the observations, that I could come up with so far. And yes it seems very power efficient, because it needs only a few entries, has symbolic indexing (no need to compute virtual and physical addresses), invalidation is done by comparing very small bitfields, and there's additional power savings from simplifying the register file. It's possible something even more power efficient could exist, but it has not been presented to me yet with an explanation of why it would be more power efficient.

> > > better thought out in the signature buffer. Indexing and invalidation, particularly.
> >
> > Which part of my indexing an invalidation explanation do you not understand?
>
> I understood it, I said it was inferior to the signature buffer.

Again that's just a hollow claim since you're not providing any explanation at all.

> > It's a fully
> > associative cache, but with just a couple entries per thread the indexing is extremely
> > cheap. The index itself is basically the SIB encoding and part of the displacement.
>
> "Basically", but not.

What do you mean "not"? I was explaining what I'm proposing to use as the L0 cache's indexing values.

> Did you understand how the signature buffer works?

Yes. It only uses the base register and displacement for indexing, which inherently gives it a lower hit rate than my proposal (all else being equal). Of course the reason they don't use the index register (and scale) as well is because they'd have to track the color of it, which is required for an out-of-order architecture. My proposed L0 cache is for an in-order architecture and thus doesn't need any register coloring, hence using the whole SIB for the index is cheap and helps identify more duplicate memory loads. So why do you still think the signature buffer is superior?

> > I answered all your questions. Also read the papers that
> > I linked to. They give you all the calculations you
> > need to determine whether an L0 cache could be viable. Let
> > me know if there's anything significant I've missed
> > that could change the equation. And again, I'm not claiming the L0 cache to be the best thing imaginable. I
> > am merely questioning David's assertion that KNL needs two L1 load ports just because x86 is a load-op ISA.
>
> The papers had nothing to do with what you propose, they were things like power
> savings of a line buffer, which is very different to what you're talking about.

On the contrary. "The Filter Cache: An Energy Efficient Memory Structure" (Johnson Kin et al., 1997) examines caches of up to 256 bytes and still concludes them to save a considerable amount of power, while line buffers are typically just a single cache line. So if the filter cache is power efficient, why not the symbolic L0 cache which doesn't even require addresses to be computed?

Secondly "Reducing Data Cache Energy Consumption via Cached Load/Store Queue" (Dan Nicolaescu et al., 2003) suggests using the L/S queue as an L0 cache, and not just for reads but also for writes. And again it achieves power savings while still computing addresses.

So whether or not using a symbolic address saves even more power is of little importance. Both these papers already provide an excellent explanation for why KNL code references the same memory operand multiple times. That said the signature buffer paper does suggest that using symbolic addresses may offer even more benefits.

So I'm done proving what I came for: it is viable for KNL not to have two L1 load ports.