Nicolas Capens (nicolas.capens.delete@this.gmail.com) on January 8, 2014 2:02 pm wrote:
> Michael S (already5chosen.delete@this.yahoo.com) on January 8, 2014 1:42 am wrote:
> > Nicolas Capens (nicolas.capens.delete@this.gmail.com) on January 7, 2014 9:55 pm wrote:
> > > Michael S (already5chosen.delete@this.yahoo.com) on January 7, 2014 4:17 pm wrote:
> > > > You ignore 2 GPR accesses and one RS access needed to do your "symbolic" matching. Or 3 RS access,
> > > > if underlying architecture is, indeed, Silvermont which holds pre-read register values in RS.
> > > > RS is significantly narrower than VPU register file, probably has more entries,
> > > > so overall I'd expect that 3 RS lokups take about the same energy as one VPU
> > > > RF lookup, but than you add L0 lookup itself on top of it and you lost.
> > >
> > > The point of a symbolic lookup is to not access any GPR
> > > registers at all. You just match the encoding of the
> > > memory operand in the instruction. For example in Eric's code there are multiple accesses to [rax+r14*4].
> > > As long as rax and r14 don't change,
> >
> > And how exactly do you track rax and r14 changes if not via existing OoO structures?
>
> Just monitor the result bus. This isn't a hard thing to do.

Sound like handwaving.

> I'm afraid you're grasping at straws. An L0 like
> this is quite feasible and see no reason why it wouldn't be more power efficient than the register file.
>

You see no reasons...



> > > and as long as the corresponding L1 cache line isn't written to, any
> > > instruction with the same source memory operand encoding can use the data that was previously loaded.
> > >
> > > > > > But that's
> > > > > > not my point. My point is - compiler never tries to make execution more power efficient.
> > > > > > [Without PGO] at best, compiler tries to make execution faster in local context. And
> > > > > > today's compilers are not particularly good even at that more modest goal.
> > > > >
> > > > > With an L0 cache there's no need to hold back on using memory operands, which saves registers
> > > > > and thus lowers register pressure, allowing better register allocation: more performance. It also
> > > > > avoids a dependency on that register, so there's also no added latency: more performance.
> > > > >
> > > > > So even if the compiler would only be optimizing for performance, if there's
> > > > > an L0 cache using memory operands would be the right thing to do.
> > > >
> > > > Memory operands are bad for Ifetch. Too many of them probably no good for Idecode.
> > >
> > > According to David's article on Silvermont, it can decode any instruction which is not micro-coded, at full
> > > throughput.
> >
> > Paper tends to perform better than silicon.
> > Paper Silvermont will easily decode 2 instructions per clock.
> > I would be positively surprised if silicon Silvermont is able to sustain decoding
> > rate of 1.7 instruction per clock for long non-microcoded instructions.
>
> Again you're grasping at straws. A decode rate of 1.7 instead of 2 would strengthens my case that
> one L1 load port suffices. And if you think two are required, then the decode rate has to be as
> close to 2 as possible. So no matter how you look at it this argument isn't helping you.
>

When I said that I have an opinion about the # of L1D load ports?
I am just saying that your far-fetched conclusions are built on sand.

> > > Also, what are you even arguing against/for here?
> >
> > I am arguing against looking at icc output as a gospel.
> > IMHO, it means nothing at all.
>
> No, you were arguing about instruction fetch/decode there. You just didn't
> explain how it's supposed to add weight to requiring more L1 read ports.
>

See above.

> > > Knights Landing has two L1 load ports but it
> > > can not sustain the decoding of two instructions with a memory operand per cycle? Obviously they'll have to
> > > ensure that KNL can sustain two AVX-512 instructions with
> > > a memory operand. Not just source operand but also
> > > destination memory operands (which would have no effect on the L1 load port question) necessitate that.
> > >
> > > > And I still didn't figure out how you are going to avoid trashing
> > > > of your tiny L0. I think, to avoid catastrophic
> > > > trashing you will need full associativity, at least 8 entries per thread and not too sloppy pseudo-LRU.
> > >
> > > Please look at Eric's code again. With just two L0 entries per thread it could eliminate
> > > 6 accesses to L1, which is plenty to require L1 to only have one load port.
> >
> > Special case.
> > Anything relying on just 2 LRUed entries without additional
> > heuristics will be brittle to the edge of uselessness.
>
> It's not a special case by any stretch. Both of Eric's examples reused memory operands where they could
> have *easily* used register operand,

Look at the 3rd Eric's example:
http://www.realworldtech.com/forum/?threadid=138897&curpostid=139104
The one with __restrict


> so this is clearly a specific compiler rule that affects all code.

Yes, it looks like compiler rule, but the rule is much less sophisticated than you imagine.

> Reusing a source operand only a couple instructions later is extremely common, but it would typically
> use a register. The fact that this code doesn't is an indication that Intel knows there's a specific
> advantage to it, and the existence of a tiny L0 cache would completely support that.

Now, if you are really interested in my opinions, they are about like that:
1. uAarch that has decode rate equal to # of VPUs looks wrong.
2. Number of load units in the core must be equal to number of load ports in L1D cache. But the ports don't have to be "true". Banked pseudo-ports are acceptable.
Pay attention, I said "must be equal each other", not "must be equal to 2".

So far the only KNL theory that makes sense to me is that everybody on RWT are confused. KNL consists of 72 dual-core modules rather than of 72 cores. Each core has 2-way instruction decoder, 1 VPU, 1 512-bit L1D load port and 1 512-bit L1D store port. I don't know whether load and store are possible in the same clock cycle.
Also each core is more likely to have 1 or 2 HW threads rather than 4.