Heikki Kultala (heikki.kultala.delete@this.tut.fi) on October 25, 2016 11:47 pm 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".
>
> No, it's mostly is because:
>
> 1) Intel chips use longer pipelines to achieve higher clock speeds
> and the longer pipelines costs transistors and chip area.

The area cost of deeper pipelining is very small compared with other microarchitectural choices. And the reason why maximum frequencies vary inversely with total area. Precisely this inverse relation is the basis for the traditional distinction between brainiac (fat core low freq) and speed-demon (narrow core high freq).

> 2) Intel has much beefier SIMD side which does nothing on integer benchmarks. Run FP SIMD codes and intel has
> much better performance/clock. Intel also does have a very beefy division unit which is used quite rarely.

I already mentioned in a former post that the reasons for Broadwell being a much bigger core are the x86 tax in the decoder translation stage plus:

3a. 256bit datapaths and SIMD units.

3b. 8-wide vs 6-wide.

3c. The rest of the x86 tax.

http://www.realworldtech.com/forum/?threadid=161978&curpostid=161998

> 3) In order to reach similar class or slightly better IPC with long pipeline(long brach preiciton
> latencies, longer cache latencies), intel has to do many other HW tricks/optimizations that apple
> don't have to do to reach similar-class ipc. These cost transistors and chip are.

That adds a small area compared to the other reasons of above.

> > 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...
>
> The pipeline of haswell is designed for 4 GHz clock speeds, so the latencies are long.
> Underclocking something is totally different than designing something for low clock speed.
>
>
> Underclocking does not reduce cycles needed for cache access, designing for low clock speed does.
> Underclocking does not reduce branch misprediction penalties, designing for low clock speed does.
>

That wasn't the point.