Exophase (exophase.delete@this.gmail.com) on February 4, 2015 8:31 am wrote:
> anon (anon.delete@this.anon.com) on February 4, 2015 6:19 am wrote:
> > Memory disambiguation also does not seem like it would improve
> > efficiency much. It increases the amount of speculation
> > that can be done, which can increase performance of course,
> > but improve perf/watt? I think IBM only implemented
> > this with POWER8, and they haven't been ones to shy away from micro architectural complexity.
> >
>
> Memory disambiguation with a simple predictor rarely incorrectly speculates. The store
> buffer has to be scanned to see if loads hit stores in flight, but most cores have been
> doing this anyway to implement load to store forwarding for ops that were otherwise started
> in-order (even the old Cortex-A8 does this, at least for the scalar part)
>
> The more execution width you have, the more important it becomes. The simple example is a
> loop with a body that loads things at the start and stores things at the end. Without memory
> disambiguation, separate iterations of that loop can't run in parallel. So maybe for A72 such
> a feature would go hand in hand with increased decode width, L/S units, ALUs, etc.
>
> AMD only started doing it with Bulldozer, Apple only started doing it with
> Cyclone, and even Intel only started with Core 2. I don't think any of that
> is an indication of the feature not being an efficiency improvement.

Memory disambiguation would be most useful with another load unit.

> > I would say perhaps improved branch prediction, reorganized cache design, and improved hardware prefetching.
> >
>
> I think they'll add a second load (and possibly store)
> unit, which Cyclone, Denver, and even Cortex-A17 have.

I would do another load unit. I don't think it's very helpful to do 2 ST/clock, especially since it makes your store buffer a lot nastier to deal with.

Prefetching and branch prediction will probably improve.

And yes, hopefully they will fix their cache design...but I think a lot of that is tied to the PD capabilities of clients (which is to say, not much).

> > I think the L2 cache might be brought in and be integrated with the core design as it is with other
> > high performance CPUs.
> > > With a more modular and configurable L3 cache shared within the cluster.
>
> By integrated you mean a separate local smallish L2 cache for each core? Right now only Intel really
> does that with their non-Atom line, although other CPUs share larger L2 caches between two cores. Doesn't
> mean that ARM won't do this, but it'll mean increasing the minimum size of their clusters a lot if
> some L3 is required. And being able to do it without L3 could have some bad design repurcussions (that
> I think the Bulldozer line suffers from) Maybe with 128KB L2 caches it won't be too bad.

> > The low associativity L1 and large shared modular L2 seems like a potential problem to me.
> >
>
> I agree, I always thought this could be a glass jaw for A15. A57 helps a little by increase
> associativity of icache to 3-way. 2-way associative L1 dcache in this day seems like a strange
> choice, even AMD moved away from that. It does give them cheap LRU replacement at least.

2W associativity is idiotic, especially for anything that even smells like a server. I made this point rather extensively when I was visiting Cambridge (Peter do you remember? :) ).

Also, if they want another LD pipe, I think they will want wider decode.

David