Sorry to say on this but what ikanayam says is true. Kyle loves to rant and rave when ever he's being challenged even when he's wrong in the 1st place. All this stemmed from his supposed unmasking of that gaming console fraud some years ago and since then, he's being having this mentallity that his word is gospel (When sadly quite often, it isn't)

This post has been edited by almostthere: May 3 2007, 01:00 AM

Well i just hoped what he say about R700 will come true heh. I guess he is ranting but i don't really mind reading rants. =x Do tell me what site to trust and what not. I'm just a junior in this kind of stuff. ._.

to be honest, none. All are based on marketing material provided which generally tells half the story. It's those that do a proper analysis of the architecture itself would have more decent factual value and less FUD. B3d would be a starting point

This post has been edited by almostthere: May 4 2007, 12:52 AM

my cousin working in AMD penang...they will launched their quad core this year and 8 core next year...

KB doesn't know shit about the R700. I can't tell you what to trust, because no one can be trusted 100%, but [H] is definitely in my 0% credibility list.

So far i find techreport to be nice, if you're not too technically inclined.

roadmaps on AMD chipset.

http://www.dailytech.com/article.aspx?newsid=7147

LOL remember the whole Kyle vs ATi motherboard debacle and the B3D forums literally p4wned him? Now that was gold.

so the 8 core will use the same mobo as the quad core rite?? or is there will be a new mobo for that 8 core

read this...8 core use different mobo cos got 2 die...

http://www.dailytech.com/Final+AMD+Stars+M...article7157.htm

This post has been edited by RiCHBoyZ: May 7 2007, 09:14 AM

amd's cache size always small then intel only (512kb) even for highend one.. when they not make it bigger (1mb @ 2mb)

Because bigger caches are slower, consume more die area, and may not necessarily improve performance that much. And Intel is really good with caches, so it's a tough act to follow.

It's not as easy as hay /b/ lets increase the cache yay! It's a large design decision.

This post has been edited by ikanayam: May 7 2007, 10:36 AM

You guys will be surprised after seeing the cache hierachy and size of L2 in Nehalem. It shrinks.

What does cache do or help anyway? I mean like it is hard for me to explain to my bro that A64 X2 3600+ with 256x2 is different with A64 3000+ with 512K. Although 256x2 is 512 mathematically because he finds it is similar, no upgrade at all.

So higher cache is better or lower is better? Or just ignore about the cache thing?

Hm... interesting, if it has a L3, then it makes sense that they will shrink the L2 and make it faster, or possibly even make it non unified L2 for latency/bandwidth & a large unified L3 for coverage.

2x256K is 256K L2 per core. In A64 3000+, the only core has dedicated 512K L2.
In single threaded software, 3000+ might work faster due to larger L2.

This sounds like Barcelona cache hierachy
I've read that Barcelona design the cache this way to increase performance in Virtualization, instead of going for shared L2. Since we are heading towards VT world pretty soon, you can roughly guess the design trend.

I have not read in depth about methods to speed up virtualization. But just from a basic design perspective (not considering virtualization) it makes sense, especially since Nehalem will probably be a monolithic quad core chip. A single large L2 would probably be too slow (both bandwidth and latency wise) to feed 4 cores (8 virtual cores with HT). So it only makes sense that they would go with a split L2.

This post has been edited by ikanayam: May 7 2007, 12:59 PM

i dont think normal home user will do much with virtualization.

I clarified my post above, even putting virtualization aside, when you have 4 fast cores to feed and you have a unified L3, then you want your L2 to be smaller and faster.

those interested in what K10 brings can look at the "AMD K10 Optimization Guide" (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf ) , Appendix A, pg 214