anon (anon.delete@this.anon.com) on January 25, 2014 6:46 am wrote:
> Nicolas Capens (nicolas.capens.delete@this.gmail.com) on January 23, 2014 11:56 pm wrote:
> > anon (anon.delete@this.anon.com) on January 21, 2014 9:24 pm wrote:
> > > > So I'm done proving what I came for: it is viable for KNL not to have two L1 load ports.
> > >
> > > Not only did you not prove anything, but we were specifically talking about this L0 cache.
> >
> > I was always talking about things in the context of the number of L1 read ports. The L0 cache was just
> > a concept to explain observations of the compiler output. You can always find flaws by drilling down
> > into smaller details, but then you're losing the bigger picture and you're attacking a straw man.
>
> Bullshit. This sub-thread is very specifically and clearly for a large number of posts, talking about the proposed
> L0 cache. Among other things, you said it was the best possibly solution that you could imagine. It's all there
> in public for anybody to read. You cannot now retreat your position and suddenly claim that the previous point
> of debate is a strawman because you had not actually retreated but were there the entire time.

I'm not retreating from anything. The L0 cache is still the best explanation I have for the KNL code. But as we get down into the smaller details of how it would be implemented, things start to matter less and less. Especially since you're not providing any explanation why the L0 cache would be inferior, I had to go back to the fundamentals of its actual purpose. The filter cache and cached L/S queue also suffice to prove my point. And lest you forget, my point was that David's article assertion that KNL's L1 cache must have two load ports because x86 is a load-op ISA, doesn't hold water. It is viable for it to have only one L1 load port and some other structure to provide a source memory operand for each instruction.

> > That said, once again you did not provide any explanation for why my proposed
> > L0 cache would not be at least as good as a filter cache or a signature buffer.
>
> Yes I did, you just refused to acknowledge it. "Oh, but it's practically
> the same thing" -- yeah, if you ignore all the details.

What details? How are they relevant? You can't just say the signature buffer paper is from a decade ago so it has be dismissed. Without an explanation why, there is no telling whether some aspect became less relevant, or more relevant than ten years ago.

> Also, you still have not acknowledged the fact that the signature paper is looking at integer workloads,
> it's 10 years old, and it does not look at power numbers, and there is no evidence it has been used. I
> should not have even brought it up, clearly, because I knew this was going to happen. It does not give
> you a free pass. It was just an example of how you would *actually* do a proper cache of this type.

Again, summing up some differences doesn't mean they make it irrelevant. So what if it only discusses integer workloads? Does the whole reasoning behind it fall apart for other workloads? Other caches exist for multiple workloads, why not the signature buffer? And while they don't look at power numbers, what makes you think power wouldn't improve? Both the filter cache and cached L/S queue papers use similar concepts to save power.

If anyone's retreating here, it's clearly you. First you point me to this paper, and then when it doesn't help make your point you say you shouldn't have brought it up in the first place? How convenient. So tell me, what exactly makes it an example of how to do a proper cache of this type? Better yet, what exactly makes the proposed L0 cache not proper for its purpose? Should I adjust the SIB+displacement symbolic addresses to just base+displacement like in the signature paper to make it work properly? Just tell me. Explain what's wrong with it according to you that keeps it from being a viable alternative to having two L1 read ports.