anon (anon.delete@this.anon.com) on January 9, 2014 7:16 am wrote:
> bakaneko (nyan.delete@this.hyan.wan) on January 9, 2014 6:24 am wrote:
> > anon (anon.delete@this.anon.com) on January 9, 2014 5:02 am wrote:
> > > bakaneko (nyan.delete@this.hyan.wan) on January 9, 2014 4:45 am wrote:
> > > > Eric Bron (eric.bron.delete@this.zvisuel.privatefortest.com) on January 8, 2014 3:28 pm wrote:
> > > > > > An extra cache layer which must be coherent with another with 72 cores
> > > > >
> > > > > only with the L1D which will include it entirely, it's not that much different than
> > > > > the "L0" icache in SNB/IVB/HSW, also read only but much smaller and simpler IMHO
> > > > >
> > > > >
> > > > > > Right, because compilers never have bugs and never emit
> > > > > > sub-optimal code for unreleased architectures. Never.
> > > > >
> > > > > I will not dismiss too fast the SW/HW codesign effort at Intel
> > > >
> > > > It is also plausible that new code needs to be
> > > > added for the new extension or the schedule for
> > > > testing the extension in the compiler is in the
> > > > future (aside from adding the instructions).
> > > >
> > >
> > > I would say they have done reasonable tuning effort of the
> > > compiler before even the HW pipeline design was finalized.
> > >
> > > Designing an ISA extension, with a new core and significantly different pipeline and memory
> > > hierarchy without doing any kind of analysis of realistic traces would be insane.
> > >
> > > Whether that work has reached public release is another story. It may be possible they will not release
> > > "optimal" code generation compiler too far in advance, to avoid competitors from reverse engineering.
> > >
> >
> > That is true, they could have used the compiler to test
> > how effective the new instructions are.
> >
> > But you can remove reverse engineering as reason for
> > the state of the compiler under the assumption that
> > internal tests have different requirements than what
> > end users need.
>
> Wrong. I'm talking about performance modelling of the pipeline and memory hierarchy. That will be
> long before any kind of stress testing. They will need traces for optimized realistic workloads.
>

You talked about both. You said the compiler
needs to be ready for performance modelling and
that the public release of the compiler may be
delayed to make it harder for the competition to
reverse engineer Intel's break throughs.

Both to which I replied.