Nicolas Capens (nicolas.capens.delete@this.gmail.com) on January 16, 2014 9:23 am wrote:
> David Kanter (dkanter.delete@this.realworldtech.com) on January 11, 2014 1:47 pm wrote:
[snip...]
>Haswell has four arithmetic execution ports instead of two, despite 'only' two load ports, >because they expect to have a purpose for them! Those two extra ports can also require a load >operand. If it was really necessary to have two load ports just for the two floating-point >execution ports, you couldn't execute many other instructions, let alone two! But Intel has >explicitly mentioned that a fourth execution unit was added to offload the vector ports. As a >consequence they also added a third AGU to sustain two loads per cycle, but nothing exceeding >that 1:2 ratio.

You have heard of specfp_rate? Haswell's FMA units ARE constrained by its load bandwidth even now.
With a latency of 5 you need 10 software visible registers just for the accumulators to fully exploit 2 FMA units and you still have to source 2 other operands for each of those 10 instruction for registers/ram. Haswell with 2 load ports and 16 registers is already starved. That's ignoring the 2 other "spare" execution units. But those will typically be used to blend/shuffle or to do flow control/loop overhead/pointer respectively so no they don't go to waste just because there is insufficient load bandwidth.

Knights [whatever] may have 32 registers but that not really enough to prevent high load bandwidth either as you still need at least one load per FMA for matrix stuff, and often have a high ratio of load:store so reusing the store port for loads is probably not a bad idea (I doubt they added a 3rd memory issue pipe).
[snip...]
> > I'm confident there is no L0 cache. I never said that the L1D
> > is dual ported, I said that it supports 2x64B reads/clock.
>
> Then it needs two read ports. Even if it's implemented with multiple banks with a single read
> port each, it adds complexity to receive two addresses, select banks, and deal with conflicts,
> and you're also consuming twice the SRAM lookup power on every dual access in the same cycle.
> With a tiny L0 cache you could avoid all that and even reduce register file pressure.
>
Yes but how it that implemented?
Either in the Load units themselves -> Still need two Issue ports for Load + 2 writeback paths.

OR

Its an extra stage in the pipeline for floating point operations (and just uses the bypass network)
I.e. Horrific on an OOO design as the scheduler needs to check the L0 indexes on each issue (as L0 hit/miss will effect instruction latency and coissue)or if we assume the FPU is in order (as in Silvermont) then that's an extra (stallable) pipeline stage that will introduce bubbles on a L0 miss - also power inefficent.

The real problem with a tiny L0 is its piss poor hit rate. A two entry structure would only work for A,A,A,A or A,B,A,C,A,D type load patterns, in any other case it will miss. So even if it does save power in a few corner cases its just an expensive (power) waste of die area in every other.

You appear only to consider the case where you L0 helps with out factoring the continued cost of it when it provides no benefit (during a miss). The problem with placing it in the pipeline or linking to instruction issue is that appears to be very hard to clock gate, at least a second load unit can be reasonably easily clock gated when not needed (or just get the store issue pipe to double duty for load as well).

> > You're just going to have to accept that given the current set of facts today, there is no way you
> > will convince me you are correct. I think the L0 cache is a terrible idea because it is a marginal
> > gain, very brittle, and adds complexity to an area that is rife with critical paths already.
>
> 40% is not a marginal gain, there's nothing brittle about it since it can easily
> be kept coherent with L1, and it can fit in the LSU without affecting any critical
> paths. All your reasons for thinking it's a terrible idea are plain wrong.
>

I guess brittle = poor hit rate in many common scenarios i.e. most of the time it would hurt FLOP/s and FLOP/watt. The P4s trace cache comes to mind.
> > When the facts change, I might change my conclusion. Until then, I'm quite confident
> > of where I stand. And I'm still open to that wager about the existence of the L0...
>
> I'm not trying to convince you that I'm correct about the L0 cache. I'm trying to convince you that
> a dual-ported L1 is not a given due to x86 being a load-op ISA. Other x86 architectures, as well
> as GPUs, have a lower MEM:ALU ratio and they're doing fine. But a single L1 load port wouldn't explain
> the code Eric has posted. So I proposed the L0 cache as something which would explain all the given
> "facts" at once. Whether that's the solution Intel ended up implementing, I don't know. It's just
> one of the viable possibilities besides assuming it "must have" two L1 read ports.

A far better explanation (if you really want to avoid two load ports) is Load elimination (especially as Intel actually have a patent filed for that) i.e. where identical loads are eliminated by PRF redirection during rename. But the only reason a complier would explicitly take advantage of such a technique is to reduce total instruction counts or to deal with register pressure, it would not offer power savings v normal register use.

Given the facts (or more absence of them) and that the complier appears to issue similar code for both Knights landing and knights corner I think the most likely explanation is the complier's back end is bugged for these targets.