Michael S (already5chosen.delete@this.yahoo.com) on January 22, 2014 8:56 am wrote:
> Stubabe (Stubabe.delete@this.nospam.com) on January 21, 2014 4:32 pm wrote:
> > >Nicolas Capens (nicolas.capens.delete@this.gmail.com) on January 20, 2014 3:48 pm wrote:
> > >> Stubabe (Stubabe.delete@this.nospam.com) on January 17, 2014 12:58 pm wrote:
> >
> > > I assume the vector pipelines are in-order with a 4-cycle latency and round-robin scheduling, just like
> > > KNC. So the L0 cache does not affect scheduling. One L0 miss becomes an L1 access, so that's fine. Two
> > > L0 misses would create a bubble in one of the pipes, but that should be rare enough and cheap enough
> > You should assume no such thing - we don't know much about that yet. Also the Load unit IS scheduled out of
> > order on Silvermont. So Load-op Instructions will issue
> > to the load queues and then on completion to the FPU
> > issue queue (in order or not) so the results have to be passed via the bypass network to the FPU (given the
> > size of the operands it is very unlikely source operands are bundled with the instruction itself so will be
> > read on issue - in fact Silvermont doesn't do this for power reasons).
> > Note the FPU part of the instruction
> > may have other dependencies so may have sit in the queue for a while. So either -> bypass network is large,
> > complex with extensive FIFO etc -> i.e. power inefficient.
> > Or more simply you allocate a temporary PRF entry
> > and get the load unit to writeback to that (which obviously
> > does not save a PRF access). Whatever you choose
> > the mechanism has to handle the worst case for program correctness. Neither looks cheaper than a PRF access.
>
> You assume that KNL VPU is similar to Silvermont FPU. IMHO, it's far more likely, that KNL
> VPU is derived from KNC and that it handles Load+Op as a single pipeline operation.
> In such design the result of the load part of load-op never touches vector RRF.
>
That seems like a very poor fit with the rest of Silvermont, to the point that it begs the question why change uarch at all. If you stick with an in-order load/execute CISC style pipeline for the vector units, basically they would gain nothing from the move to Silvermont. Also how would that interact with the out of order load unit for integer code or would we have to abandon that too? I am not implying such an approach couldn't work (this is now way outside my comfort zone) but considering KNC was basically Saltwell with big fat vector units and that all the leaked info suggests this is a Silvermont core I am not convinced they would have deviated too much from that design either (except big fat vector units).

>
> Actually, function provided by Ricardo is, indeed, a microbenchmark, but not an impractical one.
> It serves obvious real-world purpose.
> http://www.realworldtech.com/forum/?threadid=138897&curpostid=139082
>

Sorry I didn't mean to imply is wasn't practical code, I was just questioning the emphasis we are placing on the compiler output of one isolated loop...