Doug S (foo.delete@this.bar.bar) on September 23, 2013 5:31 pm wrote:
> Maynard Handley (name99.delete@this.name99.org) on September 23, 2013 11:55 am wrote:
> > If the best they can do with Cyclone is to match Intel, it's a finely balanced case and may not be worth
> > it. But Cyclone is only rev two. If they believe there is a whole lot more oomph there, another 50% in IPC
> > available just by ditching the 32-bit bwd compatibility stuff, that changes the calculation a lot.
>
>
> Errrr....do you really believe that you can gain 50% IPC by simply ditching 32 bit
> compatibility? How do you figure? I'd be shocked if you get even 5% by doing so.
>
> If that much fruit were hanging that low don't you think Intel would drop 16 and 32 bit
> compatibility in some special 64 bit only SKUs for servers and performance workstations?
> Wall Street alone would provide buy up enough hardware at top bin+++ pricing that's 50%
> faster to make it well worth the expense of designing a totally separate core for this.

I'm not assuming that simply deleting 32-bit support gives you a huge win. What I am assuming is that the less overhead you have to support, the larger your design space, and the more flexibility and time you have to add in novel ideas.
Does this get us 50%? I've no idea. But I'm optimistic. There are a number of interesting ideas that look good on paper but which Intel has never implemented (presumably because of their multiple conflicting agendas). Of course much on paper sucks, but not all.

For example perfect branch prediction (on Sandy Bridge, across SPEC) is worth about 20% improvement. One could imagine getting maybe half of that through some combination of
- use more data for generating history and hashes, to reduce aliasing. This could include throwing ASID and/or user/supervisor bit into generating the hash index.
- use an auxiliary field giving degree of confidence in a branch. Low confidence branches halt till resolved rather than guess. This saves power, which means we can afford to be more aggressive on high confidence branches.

Alternatively perfect LLC prefetching is (again, SB, across SPEC) worth about 20%. It is known that the 80% of problem loads amount to around 1.5% of static instructions, which can be identified through compiler + profiling. Adding some sort of support for these types of loads offers a big win. This requires ISA support (check, in ARMv8), support in the CPU (who knows for the A7) and support in the compiler (LLVM has people interested in profile directed feedback, though this has not yet made it into XCode in a big way as an obvious part of the UI/workflow). Done right, we can maybe get 10% here.

Let me rephrase what I said. I believe there is scope for us to see a 50% increase in IPC with the A9 and iOS9; which I attribute to having a single target of focus --- get ARM-64 as fast as possible, in both the CPU and the compiler/dev tools.
If you want to say that's not due to "getting rid of 32-bit" whatever, I don't care. My point is that human attention is a limited resource, and the more dross you can strip away, the more that resource can be spent on something useful.