Clarify this for me, please

[K20]

Could this Analyzing Efficiency of Shared and Dedicated L2 Cache in Modern Dual-Core Processors be why?

The tested systems are not particularly modern, one being a Socket 939, 2.0 GHz X2 3800+, 1MB total L2, E6 revision AMD system, the other being a X6800, 2.93 GHz, B1 Conroe Intel system.

Regardless of that when testing with 512KB+512KB and 2MB+2MB working set sizes respectively then the AMD system wins.

[jas420221]

Could this Analyzing Efficiency of Shared and Dedicated L2 Cache in Modern Dual-Core Processors be why?

The tested systems are not particularly modern, one being a Socket 939, 2.0 GHz X2 3800+, 1MB total L2, E6 revision AMD system, the other being a X6800, 2.93 GHz, B1 Conroe Intel system.

Regardless of that when testing with 512KB+512KB and 2MB+2MB working set sizes respectively then the AMD system wins.

Interesting...now what are the real world affects of these results? Anything noticeable?

[cegras]

I was going to chip in and say Savantu had his concepts all wrong - you can produce a super complex die on 65nm, sure, but ramping it up is what is the real argument here.

AMD managed to produce K10 in volume on 65nm.

Intel can produce Tukwila, but it can't do so in volume. So, yeah. After x amount of tries, you'll get success sooner or later.

But I don't want to fuel the flames, so I'll stop now.

[davidletterboyz]

it isn't quantifiable. just an experience thing.

IMHO, it is quantifiable. The key to quantify interactive performance is measuring the latency or standard deviation of FPS in games. Smoothness = lower std dev, because FPS doesn't vary much. But i don't know if there is a benchmark out there that measures these.

[jas420221]

It may be measurable by equipment, but is it noticeable to the human eye? Are you certain its the CPU that is directly affecting those 'stutters' that people claim ot have or not have?

[Aussie FX]

I think the HT link actually makes everything a lot better. It's basicly a HUGE highway what's connected to everyting in the whole system.

IMC surely helps, but not due to the latency tests you see from for example Everest but latency's we can't test (I think). I mean, if you'd run DDR800 5-5-5 (giving crap latency) or DDR1200 4-4-4 (superior latency), I wonder if this would make a whole lot of difference in your 24/7 usage experience. It's more the IMC being architectural wise good located and, as already said, gives untestable good latency.

But only the IMC isnt cutting it, I think it's more the whole connection with the whole system, the HT link.

Everest is NOT correctly reporting the memory benchmark.
Probably all synthetic memory tests are doing this to K10.
http://abinstein.blogspot.com/

[xPliziT]

ROFL!

fantastic links guys!

Finally some evidence that most bench software out there is either not well written or not up to date with the latest technology.
And thats why we get stuffed with a lot wrong results in regards to benchmarks.

EDIT: And this holds true for real-world applications as well.

[keithlm]

IMHO, it is quantifiable. The key to quantify interactive performance is measuring the latency or standard deviation of FPS in games. Smoothness = lower std dev, because FPS doesn't vary much. But i don't know if there is a benchmark out there that measures these.

BINGO. You CAN measure it. But you are correct. Current benchmarks do NOT.

As I have said many times in the past... this debate has so many similarities to the "RAID-0" versus "a single fast drive" debate.

Generally I bypass that entire debate by owning a TRUE hardware raid card. But sometimes you still get people tell you that their software RAID works just as well. (And many of them do NOT accept the fact that they HAVE software RAID.)

Typical discussion:

ME: Is the RAID built into the mb?

Fan: Yes.

ME: Is it a server motherboard?

Fan: No.

ME: Dude... you have have software raid. Period.

Fan: NO WAY... it's in the hardware... on my motherboard. It's hardware RAID.

ME: Yep. And I'll bet you believe the slowest Intel QUAD CPU are better than the fastest AMD QUAD CPU because you read it on the same site that told you that your motherboard was hardware raid, eh?

Fan: Of course... look at the benchmarks at the hackandslashdeadbodieslazerpewpew site Intel just devastates AMD in just about all of the single threaded game benchmarks!

(OOOPSSS:::: Sorry. I drifted off topic. I'm bored. In a hotel. In Ohio. On business. And I'm alergic to something in the air in this stinking state. I think I'll go drink beer and drown my sorrows.)

BUT ANYWAY: BACK ON TOPIC::: Yes... as the benchmarks mature and get tweaked... we can expect that we'll discover that the Phenom isn't the bad awful chip that many people kept trying to FUD us into believing.

[stocius]

[QUOTE=keithlm;2987233]BINGO. You CAN measure it. But you are correct. Current benchmarks do NOT.

As I have said many times in the past... this debate has so many similarities to the "RAID-0" versus "a single fast drive" debate.

Generally I bypass that entire debate by owning a TRUE hardware raid card. But sometimes you still get people tell you that their software RAID works just as well. (And many of them do NOT accept the fact that they HAVE software RAID.)

Typical discussion:

ME: Is the RAID built into the mb?

Fan: Yes.

ME: Is it a server motherboard?

Fan: No.

ME: Dude... you have have software raid. Period.

Fan: NO WAY... it's in the hardware... on my motherboard. It's hardware RAID.

ME: Yep. And I'll bet you believe the slowest Intel QUAD CPU are better than the fastest AMD QUAD CPU because you read it on the same site that told you that your motherboard was hardware raid, eh?

Fan: Of course... look at the benchmarks at the hackandslashdeadbodieslazerpewpew site Intel just devastates AMD in just about all of the single threaded game benchmarks!

(OOOPSSS:::: Sorry. I drifted off topic. I'm bored. In a hotel. In Ohio. On business. And I'm alergic to something in the air in this stinking state. I think I'll go drink beer.)[/QUOTE]


Enjoying the charms of Ohio eh mate?

[adamsleath]

well, stutter = a bottleneck somewhere doesnt it?

maybe their is a memory problem without IMC.

i can get stutters on amd depending on what's happening with graphics.

...but smoother in what application?

i think if you have everything set up right you will get just as "smooth" with a faster cpu

8or16xQ is a sweet ride with 60+ fps minimum

now someone call be an intel fanboy. cos if they do, they'd be right.

my intel is way better out of my 2 little boxes....but i guess a 3.4GHz am2 would be pretty snappy.

some 'quantitative' stuff to back up the whole smooth thing i would need....i got two smooth systems as far as i am concerned

IMHO, it is quantifiable. The key to quantify interactive performance is measuring the latency or standard deviation of FPS in games. Smoothness = lower std dev, because FPS doesn't vary much. But i don't know if there is a benchmark out there that measures these.

probably graphics card related anyway....but perhaps variations at 800x600 res or something like that could be compared between amd and intel cpu's...

your right its not the cpu its the total package cpu,ram,mobo, and video wich give that uber smooth, sily HD quality.

i spose i should have read the thread 1st

[Pla123]

I think the main reason is threads synchronization - shared L3 cache, IMC, and all cores in same chip.

My background - I am a programmer (server side).

When a complex program (good game, server, ...) is multithreaded it needs to synchronize access to some resources which are exclusive (only single thread can use them at a time). Synchronization is usually implemented by spin locks or other techniques using shared memory.

On a Phenom, the spin-lock gets cached in the shared cache L3 and it stays there - it is accessed very often by many threads and likely all cores.
Occasionally it moves from L3 to L2, L1, L2 and back to L3 when a thread/core spins on it.

On a C2D/C2Q the spin-lock stays mostly in memory and moves around between caches of individual cores. But it stays mostly in memory when 2 cores try to spin on it. So it moves Memory - L2 - L1 - L2 - Memory.

So, when 2 cores try to spin the same lock, it moves around between each core. On Phenom it moves up to L3, on C2D/C2Q it goes up to Memory.
L3 is much faster than memory - lower latency, so contentions finish a lot faster.

On benchmarks, all thread are just simple copies of each other with no synchronization between them, so this is not a factor. But real application will require synchronization and will experience the penalty described above.

Add to this the no-IMC on C2D/C2Q and you get even bigger extra penalty.

Extra explanation:

Spin lock is when a thread keeps trying to acquire the lock until it succeeds - it continuously spins on the lock until it succeeds acquiring it. (Using atomic instructions like TestAndSet)

Bellow is an example of 2 threads spinning on a lock and how the lock(an int - 32/64 bit) moves around.
(L1A is L1 cache of core A, L1B for core B, ...).
Asuming same latencies for Phenom & C2Q: L1 - 3 cycles, L2 - 15, L3 - 48, Memory - 150

Phenom:
Core A spins: Mem -> L3 -> L2A -> L1A -> Core A -> L1A (total 150 cycles)
Core A spins: L1A -> Core A -> L1A (3 cycles)
Core B spins: L1A -> L2A -> L3 -> L2B -> L1B -> Core B -> L1B (48 cycles)
Core B spins: L1B -> Core B -> L1B (3 cycles)
Core A spins: L1B -> L2B -> L3 -> L2A -> L1A -> Core A -> L1A (48 cycles)

C2Q:
Core A spins: Mem -> L2A -> L1A -> Core A -> L1A (total 150 cycles)
Core A spins: L1A -> Core A -> L1A (3 cycles)
Core B spins: L1A -> L2A -> 2xFSB/Memory -> L2B -> L1B -> Core B -> L1B (150 cycles)
Core B spins: L1B -> Core B -> L1B (3 cycles)
Core A spins: L1B -> L2B -> 2xFSB/Memory -> L2A -> L1A -> Core A -> L1A (150 cycles)

Imagine how much waiting happens when 2 cores spin on the same lock while it has been acquired by a 3rd thread. It cannot be cached for more than 1-2 instructions because both cores want exclusive access to it...
Just count how many clocks are required when the lock is transitioned from one core to another... No shared cache becomes very big penalty. Add to that FSB penalty...

Of course, good program will use as few as possible locks, but they are still required...
A single threaded program doesn't have this problem - most of the frequently used data will move in L1 or L2 cache and stay there, giving C2D higher performance (because of clock frequency).

PS: Hope it makes sense... sorry for being so long

[adamsleath]

interesting.
there must be programs that show up the benefits of AMD's IMC and cache.

[akaBruno]

Looked close.

Who wins?

[K20]

I'm not going to quote a long post which is located three above mine.

You do know that Core 2 Duo has a shared L2, there is no L2A or L2B just the L2. Of course Core 2 Quad is 2 C2D processors in the same package linked together by the northbridge. C2Q does have 2 L2 caches but Windows will schedule each task to each C2D die, will it not? Which is still useless for a 4 threaded application.

Anyway I think this extract from the Efficient Data Sharing in Intel Core Microarchitecture Based Systems presentation backs you up:

"Frequent modified cache line sharing is bad
• Intentionally – e.g. synchronization
• Mistakenly - False Sharing"

A limitation of MESI?

[SkullCracka]

Looked close.

Who wins?

Me Me Me............. I WIN...... I WIN..........

[xPliziT]

All we need now is a "fair" benchmark or application which considers all the above mentioned......
Any volunteers to write one ?

[Pla123]

You do know that Core 2 Duo has a shared L2, there is no L2A or L2B just the L2. Of course Core 2 Quad is 2 C2D processors in the same package linked together by the northbridge. C2Q does have 2 L2 caches but Windows will schedule each task to each C2D die, will it not? Which is still useless for a 4 threaded application.

Anyway I think this extract from the Efficient Data Sharing in Intel Core Microarchitecture Based Systems presentation backs you up:

"Frequent modified cache line sharing is bad
• Intentionally – e.g. synchronization
• Mistakenly - False Sharing"

A limitation of MESI?

Thanks for the correction.

So my comment doesn't apply to C2D, only to C2Q... which implies C2D should be as good as Phenom on synchronization...

[stocius]

All we need now is a "fair" benchmark or application which considers all the above mentioned......
Any volunteers to write one ?

That would be absolutely class. I'm pretty sure if you do write a fair benchmark hired gunmen will come after you from [insert from list here] {AMD, Futuremark, Intel, Nvidia,}.

[K20]

Thanks for the correction.

So my comment doesn't apply to C2D, only to C2Q... which implies C2D should be as good as Phenom on synchronization...

I'm not sure. I don't think Intel or AMD provide sufficient data for me to answer that but I think AMD has the advantage, here's some info on MESI and MOESI:

Page 468.
Table on MESI: http://download.intel.com/design/pro...als/253668.pdf

Page 3. An incorrectly coloured simple flow diagram for MESI:
http://softwarecommunity.intel.com/i...ry_Traffic.pdf

Page 168. Simple flow diagram for MOESI
http://www.amd.com/us-en/assets/cont...docs/24593.pdf

Page 219. Definition of MOESI states
http://www.amd.com/us-en/assets/cont...docs/40546.pdf

I've spent far too long trying to write this and trying to think of all the variables so let me just say I'm too tired and I'm sorry if it's useless:

C2D:
Both cores read data J (S)
One core modifies J (S-M, other becomes I)
Both cores read J, can't have 2 copies of an M line
J is written to RAM
Both cores can access J in the S state

Dual core K10:
Both cores read data J (S)
One core modifies J (S-M, other becomes I)
Both cores read J, the modified copy of J becomes O and the other core gets an S copy
Both cores can access J without having it written to RAM

In both protacols E and M are unique states, i.e. if a cache line is in the E or M states it is guaranteed to be the most up to date copy of the data. As the O state can transition to M it can be locked onto and shared without writing to RAM...

C2D:
Core A locks on and for arguments sake loads data from RAM into it's L1 in a locked E state, it works on it transitioning it to a locked M state, it can update it multiple times.
Core A unlocks
In order for the cache line to be shared it is written to RAM then called back in in the S state
Core B locks it...
Core B unlocks
Cache line is written back to RAM and then shared

K10:
Core A locks on and for arguments sake loads data from RAM into it's L1 in a locked E state, it works on it transitioning it to a locked M state, it can update it multiple times.
Core A unlocks
In order for the cache line to be shared it transitions to the O state and is given to core B in the S state
Core B locks it...
Core B unlocks
Cache line is shared without being written to RAM

I hope what I wrote makes sense but as it probably doesn't if you ask me to clear it up I should be able to do so easily.

That would be absolutely class. I'm pretty sure if you do write a fair benchmark hired gunmen will come after you from [insert from list here] {AMD, Futuremark, Intel, Nvidia,}.

AMD's the little guy, they can't afford hired gun men. They can however afford bulldozer driving, hammer wielding men. If you mentioned FutureMark because R6xx scores high on 3DMark but not FPS that's because it has a massive texture deficit compared to G8x/G9x.

[Xtrmi]

Wow a lot of writing here. I've been saying it to my freinds for a while now that my AMD opteron 939 @ 2.9 felt smoother than my q6600 at 465x7. It has to be the memory controller because with AMD I can get better memory performance. I believe its as simple as we don't have a bottleneck at the CPU so why does it matter if the Intel CPU is faster. I'm looking at AMD systems now because I'm just not happy with the Intel system. Its lame in my opinion and I'm sick of riding this Intel bandwagon because it seems like everybody is on it. I want to join the rebel side and say F them benchmarks cuz my everyday computer use does not include benchmarking my CPU. lol.

I just found this



* QX9775 - 800MHz @ 5-5-5-15 (FB-DIMM)
* QX9770 - 1600MHz @ 7-7-7-20 (DDR3)
* QX6850 - 1333MHz @ 7-7-7-20 (DDR3)
* Q6600 - 1066MHz @ 7-7-7-20 (DDR3)
* E8500 - 1333MHz @ 7-7-7-20 (DDR3)
* E6750 - 1333MHz @ 7-7-7-20 (DDR3)
* Phenom 9850 - 800MHz @ 5-5-5-15 (DDR2)
* Phenom 9600 - 800MHz @ 5-5-5-15 (DDR2)

With my q6600 the 9850 owns my bandwidth when I'm at around 1165Mhz 5-5-5-15

I know for sure that I'm not utilizing my CPU to its fullest. For example I'm running my q6600 @ 2.4 and hardly realize a difference in gaming compared to running it at 3.3. I'm pretty confident though that a boost in memory bandwidth would be felt in gaming. So I would stand to benefit if I had a 9850 right now. Please correct me if I'm wrong because I'm seriously thinking of ditching this Intel chip.

[stocius]

Wow a lot of writing here. I've been saying it to my freinds for a while now that my AMD opteron 939 @ 2.9 felt smoother than my q6600 at 465x7. It has to be the memory controller because with AMD I can get better memory performance. I believe its as simple as we don't have a bottleneck at the CPU so why does it matter if the Intel CPU is faster. I'm looking at AMD systems now because I'm just not happy with the Intel system. Its lame in my opinion and I'm sick of riding this Intel bandwagon because it seems like everybody is on it. I want to join the rebel side and say F them benchmarks cuz my everyday computer use does not include benchmarking my CPU. lol.

I just found this



* QX9775 - 800MHz @ 5-5-5-15 (FB-DIMM)
* QX9770 - 1600MHz @ 7-7-7-20 (DDR3)
* QX6850 - 1333MHz @ 7-7-7-20 (DDR3)
* Q6600 - 1066MHz @ 7-7-7-20 (DDR3)
* E8500 - 1333MHz @ 7-7-7-20 (DDR3)
* E6750 - 1333MHz @ 7-7-7-20 (DDR3)
* Phenom 9850 - 800MHz @ 5-5-5-15 (DDR2)
* Phenom 9600 - 800MHz @ 5-5-5-15 (DDR2)

With my q6600 the 9850 owns my bandwidth when I'm at around 1165Mhz 5-5-5-15

I know for sure that I'm not utilizing my CPU to its fullest. For example I'm running my q6600 @ 2.4 and hardly realize a difference in gaming compared to running it at 3.3. I'm pretty confident though that a boost in memory bandwidth would be felt in gaming. So I would stand to benefit if I had a 9850 right now. Please correct me if I'm wrong because I'm seriously thinking of ditching this Intel chip.

to AMD land! I like to be off the beaten path...been buying AMD since 1997 before the great perfromance of the Athlon. I don't get worked up about reviews all that much, I only believe what my eyes tell when I'm testing systems.

Yeah, I've got the rig in my sig and a q6600 with as near same specs as possible and I see the smoothness as I've posted before. I'm not saying Intel's all that jerky or anything but I do say AMD's smoother. Someone made a reference to feeling a change in HP when you change tires on a car, well no that's not what I'm saying. AMD is SLOWER, but smoother. I would notice a nicer ride and maybe better handling with the new tires but not a change in the engine. There's a reason tires are only rated to a certain speed.

Anyway it's only my opinion and its not gonna break Intel or AMD.

[grog]

Don't forget that AMD Hypertransport plays a strong role in system I/O latency. PCI-E interconnect using Hypertransport is very efficient.

Much of what users are seeing may not be directly CPU or memory related but rather... I/O based.

http://www.hypertransport.org/docs/w...ore_Design.pdf
http://www.hypertransport.org/docs/w...s_Parallel.pdf
http://www.hypertransport.org/

[stocius]

Don't forget that AMD Hypertransport plays a strong role in system I/O latency. PCI-E interconnect using Hypertransport is very efficient.

Much of what users are seeing may not be directly CPU or memory related but rather... I/O based.

http://www.hypertransport.org/docs/w...ore_Design.pdf
http://www.hypertransport.org/docs/w...s_Parallel.pdf
http://www.hypertransport.org/

Yes, I believe you are right. That's why I was comparing HTT to FSB on the 1st page of the thread.

[accord99]

I know for sure that I'm not utilizing my CPU to its fullest. For example I'm running my q6600 @ 2.4 and hardly realize a difference in gaming compared to running it at 3.3.

Get more powerful GPUs. The reason why you're not utilizing the CPU to the fullest is that the C2D is so powerful that even at 2.4GHz, it's enough to be GPU limited.

I'm pretty confident though that a boost in memory bandwidth would be felt in gaming. So I would stand to benefit if I had a 9850 right now. Please correct me if I'm wrong because I'm seriously thinking of ditching this Intel chip.

No, you'll see a noticeable decrease in gaming since the 9850 is a slower processor, especially in most games.

[Oldguy932]

The 9850 is like right on par with the Q6600, look at this article.

http://www.guru3d.com/article/cpu-sc...re-processors/