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