By: anon (anon.delete@this.anon.com), April 21, 2012 10:16 pm
Room: Moderated Discussions
EduardoS (no@spam.com) on 4/21/12 wrote:
---------------------------
>anon (anon@anon.com) on 4/20/12 wrote:
>---------------------------
>>Memory intensive is not necessarily the same as cache intensive.
>
>"Memory substyem intensive", now it's ok for you?
No, because I don't believe that statement is true in that case. Who can be impressed by BD's cache subsystems?
>
>>It hits a *slightly* higher frequency, which may be impressive if it were not 1/2
>>the size, 1/2 the associativity, and write-through.
>
>There is the process difference, GF's 32nm sucks, Llano wasn't able to pass 3GHz
>while it's predecessor hits 3.8GHz on 45nm.
They didn't even release the 45nm BD, did they?
>
>While Llano on this process didn't exceed 3.0GHz BD was able to hit 4.3GHz on turbo,
>43% more frequency is a lot higher.
Is that the 65W desktop part with GPU? I don't see how that's comparable, or how it helps much.
BD might do better on a better process. But so would any other CPU. And they had obviously designed to the process at some extent.
>
>>POWER7 and Intel designs are going with larger L1s and far faster L2s. I think that's a much more robust approach.
>
>On the other hand POWER7 and Intel designs have to share that cache to 2 threads
>and will halt with far less L1 misses than BD, and misses that may came from either
>thread, hey...
I don't see your point. Twice larger and twice more ways in the cache will obviously help single thread performance far more, but should still have higher performance in dual thread mode too, often.
> Changing caches sizes is pretty simple, specially higher levels,
>can we assume that, if the uarch required a faster L2 AMD would have done it like IBM and Intel did?
I don't know. AMD have always seemed pretty weak on the cache from L2 onwards, but they have had big L1 caches which seemed to make up for that.
It almost appears like they were forced to halve the L1 size in order to fit power or timing budget somewhere at a late stage. A 32K cache would make a big difference, IMO.
---------------------------
>anon (anon@anon.com) on 4/20/12 wrote:
>---------------------------
>>Memory intensive is not necessarily the same as cache intensive.
>
>"Memory substyem intensive", now it's ok for you?
No, because I don't believe that statement is true in that case. Who can be impressed by BD's cache subsystems?
>
>>It hits a *slightly* higher frequency, which may be impressive if it were not 1/2
>>the size, 1/2 the associativity, and write-through.
>
>There is the process difference, GF's 32nm sucks, Llano wasn't able to pass 3GHz
>while it's predecessor hits 3.8GHz on 45nm.
They didn't even release the 45nm BD, did they?
>
>While Llano on this process didn't exceed 3.0GHz BD was able to hit 4.3GHz on turbo,
>43% more frequency is a lot higher.
Is that the 65W desktop part with GPU? I don't see how that's comparable, or how it helps much.
BD might do better on a better process. But so would any other CPU. And they had obviously designed to the process at some extent.
>
>>POWER7 and Intel designs are going with larger L1s and far faster L2s. I think that's a much more robust approach.
>
>On the other hand POWER7 and Intel designs have to share that cache to 2 threads
>and will halt with far less L1 misses than BD, and misses that may came from either
>thread, hey...
I don't see your point. Twice larger and twice more ways in the cache will obviously help single thread performance far more, but should still have higher performance in dual thread mode too, often.
> Changing caches sizes is pretty simple, specially higher levels,
>can we assume that, if the uarch required a faster L2 AMD would have done it like IBM and Intel did?
I don't know. AMD have always seemed pretty weak on the cache from L2 onwards, but they have had big L1 caches which seemed to make up for that.
It almost appears like they were forced to halve the L1 size in order to fit power or timing budget somewhere at a late stage. A 32K cache would make a big difference, IMO.
