Simon Farnsworth (simon.delete@this.farnz.org.uk) on October 28, 2016 6:19 am wrote:
> juanrga (noemail.delete@this.juanrga.com) on October 28, 2016 2:02 am wrote:
> > Simon Farnsworth (simon.delete@this.farnz.org.uk) on October 25, 2016 11:03 am wrote:
> > > juanrga (noemail.delete@this.juanrga.com) on October 25, 2016 9:57 am wrote:
> > > > anon (spam.delete.delete@this.this.spam.com) on October 23, 2016 7:25 am wrote:
> > > > > juanrga (noemail.delete@this.juanrga.com) on October 23, 2016 6:09 am wrote:
> > > > > > anon (spam.delete@this.spam.com) on October 22, 2016 8:52 am wrote:
> > > > > >
> > > > > > > I mean
> > > > > >
> > > > > > > > Apple doesn’t always have the best performance per square millimeter,
> > > > > > > > writes Gwennap, but it makes up for it in efficiency per clock cycle
> > > > > >
> > > > > > > that's not how it works.
> > > > > >
> > > > > > His first claim is correct, Apple Hurricane doesn't have the best performance per area,
> > > > > > but this is expected because it is a latency-optimized core not a throughput optimized-core.
> > > > > > About his second claim if by "efficiency per clock cycle" he means IPC/Area then his claim
> > > > > > is wrong or right depending if he is comparing to Intel or to other ARM cores.
> > > > >
> > > > > My point is that perf = clockrate * ipc. Whether the ipc is high with low clockrates
> > > > > or abysmal with insane clockrates doesn't matter at all for perf/area. Same
> > > > > perf and same area mean same perf/area, regardless of the ipc.
> > > >
> > > > But he talks about "efficiency per clock cycle" which suggest he is talking about
> > > > IPC/Area, not about Perf/Area. And the superior IPC/Area of Apple chips compared
> > > > to Intel chips is related to ARM64 efficiency: the well-known "x86 tax".
> > > >
> > > > > IPC/area is nice and all but it doesn't buy you anything. I can get you tremendous IPC
> > > > > by running the core so slow that I get a RAM to register load to use latency of 1 cycle.
> > > >
> > > > The variation of IPC with clocks is very small and you can only get huge IPC gains by
> > > > setting extremely low clocks, but that is not happening here. Hurricane is clocked at
> > > > 2.34GHz. Underclocking a 4GHz Haswell chip to 2GHz increases the IPC by less than 5%.
> > > > Apple achieving IPC parity with best Intel designs is not due to lower clocks...
> > >
> > > That claim does not fit my understanding of how IPC gets
> > > exploited in real world chips. Downclocking Haswell
> > > won't increase IPC by much, because the design is for high clock rates, and thus the increased IPC from a
> > > lower clock is only available because the ratio between memory speed and processor speed is reduced.
> > >
> > > However, if you're designing to a target clock speed, you can get much higher IPC on a comparable
> > > process if your clock speed is lower than if it's higher; this is simply because if the processes
> > > are comparable, the FO4 time is comparable, but at 2 GHz, you can fit twice as many FO4 time units
> > > (thus twice as many transistors) in the critical path compared to a 4 GHz clock.
> > >
> > > Thus, for your claim to be true, either the process Apple is using is far behind Intel, such that
> > > the FO4 time is about twice that of the Intel process (so Apple get the same number of transistors
> > > in the critical path as Intel, but at half the clock speed), or Apple is leaving performance
> > > on the table, by designing for a target clock of 4 GHz, then only achieving 2 GHz, when they could
> > > achieve higher IPC and higher performance by designing around the 2 GHz target clock.
> > >
> > > Assuming that Apple aren't being idiots, and that TSMC/GloFo/Samsung
> > > processes are comparable to Intel's processes
> > > (within 20%, say), the most likely explanation is that they're
> > > getting their IPC by exploiting the longer clock
> > > cycles to run more logic per clock cycle. This, in turn,
> > > means that the chip is unlikely to scale to the same
> > > high clock speeds as an Intel chip does, because they run out of FO4 delay as the clock goes up.
> > >
> > > Equally, of course, this implies that an Intel core run at mobile speeds is leaving performance on
> > > the table - you've designed around the constraints of high speed operation, then decided to clock lower,
> > > when you could have designed for the lower clock, and had more logic running per clock cycle.
> >
> > Essentially the same rule applies upwards and downwards, only parameters vary.
> >
> > If your design is optimized for 4GHz and underclocking to 2GHz increases the IPC by less than 5%, then
> > if your design is optimized for 2GHz, overclocking it to 4GHz will reduce the IPC by a similar amount.
>
> The same rule does not apply upward and downward. If it did, I could reliably overclock
> a Pentium III to 4 GHz, just as I can downclock a modern Intel chip to 800 MHz.
>

I didn't wrote "the same" but "Essentially the same" and I mentioned explicitly that parameters vary (critical path timing, clock skew, jitter...).