Exophase (exophase@gmail.com) on 4/26/12 wrote:
---------------------------
>The point is that it can't be a very reliable document if it omits something so fundamental.

Indeed, AMD docs used to be better.

>Agner Fog's documentation indicates that the AGUs can perform loads without issuing
>to the EX ports, and David said that he doesn't see why this would not be the case
>- can you think of anything, outside of the questionable SOG suggesting it?

It's contradictory:
1) If there is no AGUx to AGUx forwarding than L1 latency tests would be hit by a penality and indicate more than 4 cycles, but they didn't;

2) Maybe the latency is 3 cycles and they report 4 because of the no forwarding penality, but then load-execute instructions with forwarding would take just 4 cycles, IIRC they take 5, Agner omits this part.

>Or maybe by memory subsystem you mean the load/store units themselves? Because
>that is indeed where BD has improved. If this is what you mean then I think we have a communication problem.

I mean the load/store units, L1, L2, L3, memory, prefetchers and everything that goes on the middle, everyone else seens to just look at L1 size, L2 latency, L3 latency and memory latency.

>But why would the performance impact be limited to
>only the execution width or the memory subsystem and never both?

Well... There are some integer workload were BD is actually faster than GH by a significant amount, from were the performance gains come?

These workloads happens to be memory intensive...

>Do you really think that going from ~12 to ~20 cycles L2 latency while not increasing
>the clock speeds nearly as much carries zero penalty? And that going from 64KB L1
>at 3 cycles to 16KB L1 at 4 cycles, albeit more associative, isn't going to hurt
>some workloads?

Because it is not just "small L1 and slow L2",

1) Yes, the frequency didn't improved much over GH45, but that was not because of the uarch, look at Llano frequency, the uarch itself allows for a much higher clock and all latencies payed for it, sure, the end result is that the end product performance sucks, but this says nothing about uarch improvements, put the previous memory subsystem on such slow process and the end product will sucks even more.

2) There is more than just two metrics, even with a small L1 the cache hit rate is between 95%-99%, if we would size L2 to meet this hit rate (for the second level 1 - L2 miss/ L1 miss) the cache would be very big, the 256kB after a 32kB L1 on Intel or 512kB after a 64kB won't do it, they will be more in the 80%-95% range, the size difference between L1 and L2 aren't that big, now the penality of L1 miss, it is not just the latency, but what happens at the core when a L1 miss happens, will it flush the pipeline? Reissue a lot of instructions? Halt? Immediatly execute independent instructions? The behaviour varies a lot here and is hard to find the details by testing, K-8 were pretty bad handling L1 misses it was almost like a halt, on the Intel side they reduced L2 size and latency after implementing SMT, SMT should perform like two cores on workloads with very low IPC and dominated by cache/memory latency, but that was not the case with Nehalem, maybe L1 misses weren't perfectly dodged by SMT.

Since there other penalities in L1 misses other than latency and other methods to reduce these penalities, without knowing how BD behave when a L1 miss happens it is impossible to say precisely how hard the 20 cycle latency strikes, apparently it doesn't have to hit the red button when a L1 miss happen.

Oh, I have actually tested every processor cited in item 2 except BD, and the one I know better is K-8.

3) There is the up side in that L2, the size, it is 20 cycles and that is, L2 misses are much more rare, neither K8/GH or BD instruction window is big enough to hide memory latency, so while L1 miss may not means a halt L2 miss means.