Macro/Micro architectural imporvements of K8L(K10) over K8

Quote:

---

Originally Posted by Wrench

Dood I did do a fair bit of programing and seting up all the geometry is handled by the cpu still as well as physics and AI. Graphic cards handle things like textures, T&L, Vertex shader, and pixel shaders. Most 3D games require Floating point math unlike 2d games.

---

I'm not saying games don't use floating point math, just that most game code is integer based. The heavy FP grunt work is done by the GPU, and the CPU probably uses FP for things like physics..

AI code is Integer though as far as I know.

One guy once told me that the reason why games use INT more than FP is because historically, x86 CPUs have always had a weak FP unit.

So game developers were forced to use integer rather than FP..

Quote:

---

This is why the Northwood was a lame duck in most games compared to the A64.. A64 had a very strong FPU and the Netburst architecture didn't. Now by your reasonging the Netburst should have whomped the a64 since the Netburst architecture had almost an equivalent integer functionality to the a64 (the c2d has a damn good FPU and a short pipeline, since its based of the p3 FPU which was a damn good FPU compared to the Netburst, it whipes the floor with the a64). I haven't programmed in about a year and half but things haven't changed to hell of a lot.

---

Actually, the P4 had a very powerful FPU (SSE2) but it was harder to optimize for due to the peculiarities of the Netburst architecture. It's x87 FPU was weak, but Intel did that on purpose so that developers would be forced to use SSE2.

Anyway, if your theory is correct, then how do you explain Dothan and Yonah beating the K8 in gaming?

Dothan and Yonah had much weaker FPUs than the K8, yet they still managed to beat the K8 in gaming clock for clock, once the FSB was raised a bit.

And while the C2D has a strong FPU, it is FAR stronger in INT.

Just check the Spec scores.. C2D opens a can of whoopass on the K8 in INT..

umm P6 architecture has always been strong for Integer math

Quote:

---

Originally Posted by Carfax

I'm not saying games don't use floating point math, just that most game code is integer based. The heavy FP grunt work is done by the GPU, and the CPU probably uses FP for things like physics..

AI code is Integer though as far as I know.

One guy once told me that the reason why games use INT more than FP is because historically, x86 CPUs have always had a weak FP unit.

So game developers were forced to use integer rather than FP..



Actually, the P4 had a very powerful FPU (SSE2) but it was harder to optimize for due to the peculiarities of the Netburst architecture. It's x87 FPU was weak, but Intel did that on purpose so that developers would be forced to use SSE2.

Anyway, if your theory is correct, then how do you explain Dothan and Yonah beating the K8 in gaming?

Dothan and Yonah had much weaker FPUs than the K8, yet they still managed to beat the K8 in gaming clock for clock, once the FSB was raised a bit.

And while the C2D has a strong FPU, it is FAR stronger in INT.

Just check the Spec scores.. C2D opens a can of whoopass on the K8 in INT..

---

:D

http://geoffhutchison.net/gallery/ma...serialNumber=2

Quote:

---

Originally Posted by Carfax

C2D has higher theoretical SIMD throughput, but the keyword is theoretical. I think C2D can issue a max of 6 SSE instructions per cycle, but it's very hard to do so.

It will be very interesting to see which chip has the lead in vectorized apps..

I'm thinking that C2D will have an edge like you, but not very much..

Whats even more interesting, will be Barcelona's gaming performance.

Games seem to favor integer performance over FP, and C2D is the master of integer so......

Either way, we the consumer will win! :banana:

---

Although already answered, I'll give you my view on today's game codes:
The time of integer calculations in games is over. As long as there were many 486 around, the programmers used a lot of fixed point arithmetics with integer numbers. Later they switched to mixed code as necessary (e.g. floating point for vector operations and fixed point for drawing of texturized and shaded triangles with approximated perspective correction). Currently games still do a lot of calculations, especially (still) some vector operations on 3D data, a lot of physics and AI, on the CPU. But since stuff like AI, bot script P-code interpreters etc. depend more on integer units, memory subsystem and branch prediction, the overall effect of core changes is more complicated than just that implied by changes in the FPU. Just think of caches, mem accesses (+prefetching), branching etc.


About the six SSE ops per cycle throughput on C2D... how might they look like?
For SSE FP code:
2 FP ops, 1 move, 1 load, 1 store (+1 for store address as a fused µOp)
For SSE INT code:
3 INT ops, 1 load, 1 store (+1 for store address as a fused µOp)

So it's actually only up to 5 ops per cycle, since the 6th is one of the 2 operations necessary for a write operation (part of a fused µOp).

C2D has an advantage in situations, where explicit mem operations and a reg move come with a mul and an add (all FP SSE ops)
and still, if the load is a mem operand.
So what could be executed in one cycle might look like this:
ADDPD r->r, MULPD r->r, MOVAPD r->r, MOVAPD r->m, MOVAPD m->r (although that coulnd be decoded at that rate)
or
ADDPD m->r, MULPD r->r, MOVAPD r->r, MOVAPD r->m (this is nearly sustainable by the decoder)
The register read stall bottleneck (see Agner Fog's microarchitecture.pdf) shouldn't limit that in most kinds of code.

For integer SSE code there can be even up to 3 ALU ops plus 2 mem ops (of which one could be a mem operand). That's another possible advantage for C2D. However, the C2D can't issue more than 5 SSE µOps per cycle, because that 6th µOp is actually part of the fused µOp of a store.

K10 in a best case could do:
ADDPD m->r, MULPD m->r, MOVAPD r->r (2 calculations, 1 reg move, 2 loads, equals 5 C2D µOps, while C2D couldn't do 2 loads).


The integer performance of C2D
The int op throughput is just a part of the equation. Some performance improvements were also brought in by improvements in prefetching, branch handling (e.g. loop detection, prediction and fused MacroOps), better memory subsystem (incl. cache bandwidth) etc.

For SPEC CPU2006 benchmarks the instruction mix is like ~20% branches, ~30% loads, ~10% stores for INT and ~5% branches, ~35% loads and ~8% stores for FP.
There is a nice analysis of C2D running SPEC CPU2006 here:
http://www.spec.org/workshops/2007/a...Benchmarks.pdf

They say, that L2 is very important for these benchmarks. How this will work out for K10 remains to be seen.

Great post Dresdenboy..

It's good to have knowledgeable people like you on this board. :)

Quote:

---

Originally Posted by Carfax

I'm not saying games don't use floating point math, just that most game code is integer based. The heavy FP grunt work is done by the GPU, and the CPU probably uses FP for things like physics..

AI code is Integer though as far as I know.

One guy once told me that the reason why games use INT more than FP is because historically, x86 CPUs have always had a weak FP unit.

So game developers were forced to use integer rather than FP..



Actually, the P4 had a very powerful FPU (SSE2) but it was harder to optimize for due to the peculiarities of the Netburst architecture. It's x87 FPU was weak, but Intel did that on purpose so that developers would be forced to use SSE2.

Anyway, if your theory is correct, then how do you explain Dothan and Yonah beating the K8 in gaming?

Dothan and Yonah had much weaker FPUs than the K8, yet they still managed to beat the K8 in gaming clock for clock, once the FSB was raised a bit.

And while the C2D has a strong FPU, it is FAR stronger in INT.

Just check the Spec scores.. C2D opens a can of whoopass on the K8 in INT..

---

Unless your a programmer or at least was one I am not gone go any further with this argument. You believe what you want and I will stick with mine.

independent clock management per core but not voltage right?

Quote:

---

Originally Posted by -Sweeper_

independent clock management per core but not voltage right?

---

Exactly.