EduardoS (no@spam.com) on 4/21/12 wrote:
---------------------------
>anon (anon@anon.com) on 4/21/12 wrote:
>---------------------------
>>No, because I don't believe that statement is true in that case. Who can be impressed by BD's cache subsystems?
>
>You saw no benchmarks, did you?

I don't understand what you mean. I have seen lots of BD's benchmarks, yes. I have also seen the statistics for its caches, and they are not good. End of story.

>
>>They didn't even release the 45nm BD, did they?
>
>No, that's why I'm comparing Llano to Deneb, if they had released a 45nm BD I could compare it directly to Deneb.
>
>>Is that the 65W desktop part with GPU? I don't see how that's comparable, or how it helps much.
>
>No, it's the 100W part that hits 3GHz with 1.4V.

Oh, I was looking at 2.8GHz version.

>
>We know Greyhound target clock, we now that, with 0.025V more BD clocks at 4.3GHz,
>it isn't difficult to understand that the frequency increased a lot, is it?

Totally different power constraints and architecture, so again I don't know what this is proving.

>
>>BD might do better on a better process. But so would any other CPU.
>
>But there are only two CPUs on this process, Llano and BD, the claims about frequency
>gain won't make sense if we compare to CPUs on a better process, right?

What I mean is that I don't know how much sense it makes to compare Llano with its parent. And also even if you do know about AMD's 32nm process, then it doesn't affect that BD is not a good architecture for that process. The real world is really the only way to ultimately evaluate it.

>
>>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.
>
>And will either have higher latency or limits clockspeed.

Wrong. POWER7 is manufactured on 45nm, and has 2 cycle load to use 32KB 8 way L1 cache, and clocks up to nearly the same as BD. It uses more power of course, but it does vastly more work per clock.

>
>>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.
>
>Have ever passed on your head that, since their L1 was so big the L2 didn't have to be too fast?

Err, their L1 is tiny. This is my whole point, which is why BD's cache design is not a good one. What is so hard to grasp about this?

>
>>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.
>
>It really doesn't look so, there are too many numbers sugesting the initial idea
>was 16k, it is not like Via Isaiah and that 4/3 relation all over timmings.

Well then their slow L2 cache baffles me.