David Kanter (dkanter.delete@this.realworldtech.com) on February 4, 2015 11:25 am wrote:
> Memory disambiguation would be most useful with another load unit.
>
> 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.
>

I don't think it's a coincidence that Core 2 both increased width across the board and added memory disambiguation, all while not adding a second store port until two uarch generations later. Although I do of course agree that disambiguation would be more effective with a second load port.

I have written lots of code which has a higher than 1:2 load to ALU density for decent sized chunks or loop bodies, so I do think a second load unit would help a lot. Even more so if they're adding a third ALU.

> Prefetching and branch prediction will probably improve.
>

From what I could gather in the TRMs, the prefetching to date seems to be based on observing access patterns in the cache (originally, from cache misses). I don't know if they've moved beyond this already, but if not they'd benefit from having IP-hashed stream detection.

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

When you say fix it, are you referring to latencies, size, hierarchy arrangement, or what? Size and hierarchy arrangement are really pretty much the same as everyone else in these segments, unless you count Broadwell-Y.

More and more clients will be using the "POP"s that ARM is making, so the baseline will at least be how good ARM and their partners are at this reference implementation.

> 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? :) ).
>

I still don't think there was anything to this designed-for-servers point, but on the other hand maybe the original frequency targets were a little too much for the markets they did hit.

2-way is still plenty bad for a lot of non-server tasks.

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

Cortex-A17 seems to benefit a lot from the second load pipe while still not even being three wide. I'd go as far as to say that even A53 would benefit a lot from a second load pipe, actually maybe even more than A17 does, but I don't know what that does to the area and power targets for a CPU like that.

Maybe they'll have wider decode only for 64-bit, or only for non-Thumb2 or something. I'm wondering how much stuff they could have really added while still consuming less power at the same clock speed; so never mind improving overall perf/W, that's a much stricter requirement. I think they must have found some big things to optimize.

Oh, and another feature they might draw from the well is instruction fusion, particularly cmp + branch.