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.

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