anon (anon.delete@this.anon.com) on February 4, 2015 11:27 pm wrote:
> Exophase (exophase.delete@this.gmail.com) on February 4, 2015 2:33 pm wrote:
> > 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.
>
> Silvermont does not do memory disambiguation, despite Intel having perhaps more experience than
> anyone with it. Although it is their first gen core, so it's possible they decided to limited
> some complexities. It does suggest that it's not the lowest hanging of fruit, though.
>
> >
> > > 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.

Fixed format:

                   L1I         L1D                    L2

A15 (Exynos 5250)   32K,2-way  32K,2-way,4-cycles          1M,16-way,21-cycles

A57                 48K,3-way  32K,2-way,5-cycles(?)  512K-2M,16-way,??-cycles

Denver             128K,4-way  64K,4-way,?-cycles          2M,16-way,18-cycles

A8                  64K,?-way  64K,?-way,4-cycles          1M,??-way,??-cycles + 4M L3

Silvermont          32K,8-way  24K,6-way,3-cycles          1M,16-way,14-cycles

I include the A15 only to see the L2 latency at 1MB. A57 may be a little better, but I'm not sure. Anybody has the numbers?

So of the modern 64-bit mobile CPUs, I would say A57 has the worst cache hierarchy. Unless the L2 is faster than Silvermont's at 1MB (because its L1 is significantly worse). But I doubt it is, I would say the L2 is closer to 20 cycles than to 10.