Kevin G (kevin.delete@this.cubitdesigns.com) on September 22, 2020 6:10 am wrote:
> Andrei F (andrei.delete@this.anandtech.com) on September 18, 2020 1:04 am wrote:
> > anon (anon.delete@this.anon.com) on September 17, 2020 7:10 pm wrote:
> > > AnandTech's (SPEC ST performance) review is here: anandtech.com/show/16084/intel-tiger-lake-review-deep-dive-core-11th-gen/8
> > > However not all is good: TigerLake
> > > experiences a noticeable IPC regression compared to IceLake. The memory subsystem is unable
> > > to keep up with the higher clocks, and the reworked cache is not enough.
> > >
> >
> > I just want to add on that sentence as that's not what I wrote
> > in the piece: I don't think the memory subsystem is to blame.
> >
> > It's significantly stronger than ICL and showcases *much* better DRAM latency and significant
> > single core bandwidth uplift. 429.mcf showcases great scaling well beyond clocks, showing
> > that latency for example is not to blame. In my opinion it's a regression *because* of the
> > reworked cache, as essentially the L3 is now 20% slower per clock versus ICL.
>
> One thing Intel certainly has been improving is there security due various exploits and side channel
> attacks that have appeared over the past couple of years. Looking at the time line, especially
> factoring in Intel's knowledge prior to public disclosure, Tiger Lake would be the first chip to
> have the fixes in place that required significant alterations to the design. An example would be
> some of the bypass networks being removed or having extra logic added to them to enhance security.
> While not explicitly written to use them, the algorithms used by SPEC could have been an optimal
> fit for using them in the design. For Tiger Lake, what used to be optimal is not nearly as much
> or the gains provided by the bypass network are not as significant as they used to be.

It is not impossible but I think it is unlikely. I can't think of any version of the side channel issues that would have a particularly expensive hardware-only fix. They either have cheap fixes (usually very cheap), or can't really be fixed and basically being ignored.

There is another category of stuff where the fix is some combination of hardware support and software changes (e.g., special MSRs to flush structures), and here newer chips are usually getting faster as the hardware side of the support gets better.

SKX had quite poor performance in the "middle" of the memory hierarchy (around L3) for ST loads (I measured 6 bytes/cycle bandwith or something like that), so it is not that strange that perhaps TGL, which superficially shares some SKX characteristics, might have inherited some of those tradeoffs.