Stubabe (Stubabe.delete@this.nospam.com) on January 23, 2014 9:06 am wrote:
> Michael S (already5chosen.delete@this.yahoo.com) on January 22, 2014 8:56 am wrote:
> >
> > 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?

One of my crazy thoughts tomorrow, when I wrote the post above, was that "May be, they keep Silvermont L1D as is and add separate L1D for VPU?"

> 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

[Nitpick]
Non-vector part of KNC is not similar to Bonnel/Saltwell. It is derived from P54C with few modifications that help clock speed and hardware MT. In particular, integer load+op instructions are handled in P5 manner as two pipeline operations rather than in Bonnel manner as a single operation. Only VPU part of KNC somewhat resembles Bonnel/Saltwell, but even here pipeline is significantly shorter.
[/Nitpick]

> 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).
>

May be, Silvermont is here to test the water for the next step - removal of 3/4th of VPU?
100W dual-capable Silvermont-derived MIC with 128-bit VPUs (or even 64-bit) could serve as Intel's answer to ARM servers hype and to the whole cloud hysteria.
Of course, Intel's top management is sufficiently technically savvy to know that they will not sell enough of "general-purpose" KNLs to make a difference to their bottom line, but regardless of bottom line it is important to keep less technically savvy Wall Street crowd happy.

> >
> > 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...
>

Well, I agree with "garbage in, garbage out" sentiments if "garbage in" means icc compiler output and "garbage out" are our speculations, based on this output.