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

Quad-core
- Native quad-core design
- Redesigned and improved crossbar(northbridge)
- Improved power management
- New level of cache added, L3 VICTIM
Power management - DICE(Dynamic Independent Core Engagement)
- Supports separate CPU core and memory controller power planes to allow CPU to lower its power state while the memory controller is running full bore
- Enhanced AMD's PowerNow allows individual core frequencies to lower while other cores may be running full bore
Virtualization improvements
- Nested Paging(NP):
* Guest and Host page tables both exist in memory.(The CPU walks both page tables)
* Nested walk can have up to 24 memory acesses! (Hardware caching accelerates the walk)
* "Wire-to-wire" translations are cached in TLBs
* NP eliminates Hypervisor cycles spent managing shadow pages(As much as 75% Hypervisor time)
- Reduced world-switch time by 25%:
* World-switch time: round-trup to Hypervisor and back
Dedicated L1 cache
- 256bit 64kB (32kB instruction/32kB data)
- 2 x 128bit loads/cycle
- lowest latency
Dedicated L2 cache
- 128bit 512kB
- 128bit bus to northbridge
- reduced latency
- eliminates conflicts common in shared caches - better for virtualization
Shared L3 cache
- 128bit 2MB
- Victim-cache architecture maximizes efficiency of cache hierarchy
- Fills from L3 leave likely shared lines in the L3
- Sharing-aware replacement policy
- Expandable
Independent DRAM controllers
- Concurrency
- More DRAM banks reduces page conflicts
- Longer burst length improves command efficiency
- Dual channel unbuffered 1066 support(applies to socket AM2+ and s1207+ QFX only)
- Channel Interleaving
Optimized DRAM paging
- Increase page hits
- Decrease page conflicts
Re-architect northbridge for higher bandwidth
- Increase buffer sizes
- Optimize schedulers
- Ready to support future DRAM technologies
Write bursting
- Minimize Rd/Wr Turnaround
DRAM prefetcher
- Track positive and negative, unit and non-unit strides
- Dedicated buffer for prefetched data
- Aggressively fill idle DRAM cycles
Core prefetchers
- DC Prefetcher fills directly to L1 Cache
- IC Prefetcher more flexible
* 2 outstanding requests to any address
HyperTransport 3
- up to four 16bit cHT links
- up to 5200MT/s per link
- un-ganging mode: each 16bit HT link can be divided in two 8bit virutal links

CPU Core IPC Enhancements:
Advanced branch prediction
- Dedicated 512-entry Indirect Predictor
- Double return stacksize
- More branch history bits and improved branch hashing
History-based pattern predictor
32B instruction fetch
- Benefits integer code too
- Reduced split-fetch instruction cases
Sideband Stack Optimizer
- Perform stack adjustments for PUSH/POP operations “on the side”
- Stack adjustments don’t occupy functional unit bandwidth
- Breaks serial dependence chains for consecutive PUSH/POPs
Out-of-order load execution
- New technology allows load instructions to bypass:
* Other loads
* Other stores which are known not to alias with the load
- Significantly mitigates L2 cache latency
TLB Optimisations
- Support for 1G pages
- 48bit physical address (256TB)
- Larger TLBs key for:
* Virtualized workloads
* Large-footprint databases and
* transaction processing
- DTLB:
* Fully-associative 48-way TLB (4K, 2M, 1G)
* Backed by L2 TLBs: 512 x 4K, 128 x 2M
- ITLB:
* 16 x 2M entries
Data-dependent divide latency
Additional fastpath instructions
– CALL and RET-Imm instructions
– Data movement between FP & INT
Bit Manipulation extensions
- LZCNT/POPCNT
SSE extensions
- EXTRQ/INSERTQ (SSE4A)
- MOVNTSD/MOVNTSS (SSE4A)
- MWAIT/MONITOR (SSE3)
Comprehensive Upgrades for SSE
- Dual 128-bit SSE dataflow
- Up to 4 dual precision FP OPS/cycle
- Dual 128-bit loads per cycle
- New vector code, SSE128
- Can perform SSE MOVs in the FP “store” pipe
- Execute two generic SSE ops + SSE MOV each cycle (+ two 128-bit SSE loads)
- FP Scheduler can hold 36 Dedicated x 128-bit ops
- SSE Unaligned Load-Execute mode:
* Remove alignment requirements for SSE ld-op instructions
* Eliminate awkward pairs of separate load and compute instructions
* To improve instruction packing and decoding efficiency

K8L(K10) large die Shot

Source: AMD slides, and other sources from Internet

P.S. Any additional data or informations will be highly appreciated

A source would be nice.

A link would be nice

I thought we had just come to realize that K8L doesn't exist, or rather has been with us for quite some time (K8 Low-Power, that is Turion 64). Instead the AMD dual-cores (X2) were K9 and what we used to refer to as K8L is in reality the K10. (According to Inq it was their own Charlie who made up the K8L name.)

(Thread here.)

Yes, and source, please?

~ Kris

Quote:

---

Originally Posted by LOE

gOJDO - you got no info on L1 and L2 cache interface - I heard it is going to be twice as wide as K8

---

As far as I know, the K10's L1 and L2 cache interface will be 256bits, but dual split like the K8.

In other words, 2x128. Right now, the K8 has a 128 bit cache bus, which is dual split (2x64).

The C2D just has one big 256bit wide interface.

As for which implementation is better, I don't know.

*Edit* Gojdo just added some more stuff. According to the updated info, the L2 cache is only 128-bits wide! But the L1 cache is 256-bits? WTH?

Sounds impressive if true. I have no idea what it all means though. heh
On the other hand, gOJDO might be just trying to make a point that without a source, it doesn't mean it's true.

L1 cache size remains the same, 64KB for Instructions and 64KB for Data.

Yes, L1 bus is 2x128bit and L2 is 1x128bit.

Quote:

---

Originally Posted by doompc

L1 cache size remains the same, 64KB for Instructions and 64KB for Data.

Yes, L1 bus is 2x128bit and L2 is 1x128bit.

---

You'd think they would have expanded the bus to full 256 bit so as not to starve the execution engines..

Then again, I'm no engineer and there is probably a good reason for them choosing to stay with a 128-bit data bus on the L2 cache.

Quote:

---

Originally Posted by Carfax

*Edit* Gojdo just added some more stuff. According to the updated info, the L2 cache is only 128-bits wide! But the L1 cache is 256-bits? WTH?

---

No info about 256bit L2. Most probably is 128bit. The bus to the crossbar is 128bit, thus the access to the L3 is 128bit also. Because the L3 is going to be used as exclusive, most likely the L2 is 128bit.
Can anyone confirm this?

Quote:

---

Originally Posted by gOJDO

Source: Internet

---

LOL!

Reduced latency L1???? Does that mean it's 2 cycles now? I don't really believe this.

Also, for the D-TLB, do you mean 48-entry?


- DTLB:
* Fully-associative 48-way TLB (4K, 2M, 1G)

AMD Analyst Day slides would seem to point to 128bit data paths for L2.

Quote:

---

Originally Posted by Shadowmage

Also gODO just took it from Ace's Hardware:

http://www.aceshardware.com/forums/r...5159&forumid=1

---

Quote:

---

Originally Posted by Carfax on Ace's

This is something I saw on Xtremesys. The guy who posted this, did not post a source, but if he does, I'll edit this post and include it.

---

;)

The path to the northbridge has been widened to 128 bit.
Athlons have 2 individual L1 buses, both has been widened to 128 bit. L1 must have 256 bit bus in order to allow 32Byte Instruction Fetch.

L2 seems to have not changed, since it is exclusive victim cache and the CPU loads data from memory to L1 cache, it's ok here.

No word about L3 cache, but it must be managed by the crossbar, with agressive data prefetch during idle cycles and a large WriteBack bufer.
AMD said that the L3 cache will not be exclusive nor inclusive, beeing a shared victim cache it will be a bit of both.

Quote:

---

Originally Posted by largon

;)

---

That's why I edited that out when I saw that :p

Quote:

---

Originally Posted by gOJDO

Source: Internet

---

As far as I can tell, most of this is from Dresdenboy's list at SI.

Ironically, DDB posted a link to it at Ace's yesterday, and it was mostly ignored. Then gOJDO posted it here. Then Carfax saw it here and posted it on Ace's again, which started a big discussion.

It's all in the formatting. :)

Oldblue is right,the majority of this info was posted by DDB on SI board,then he linked it to his post at Ace's ,which gojdo copy/pasted here without crediting DDB.
Oh well..

you forgot the migration bus for the IMC

Quote:

---

Originally Posted by doompc

The path to the northbridge has been widened to 128 bit.
Athlons have 2 individual L1 buses, both has been widened to 128 bit. L1 must have 256 bit bus in order to allow 32Byte Instruction Fetch.

L2 seems to have not changed, since it is exclusive victim cache and the CPU loads data from memory to L1 cache, it's ok here.

No word about L3 cache, but it must be managed by the crossbar, with agressive data prefetch during idle cycles and a large WriteBack bufer.
AMD said that the L3 cache will not be exclusive nor inclusive, beeing a shared victim cache it will be a bit of both.

---

Great explanation DoomPC.. You sound like a man who knows what he's talking about :toast:

@oldblue
Most of Dresdenboy's list at SI is from AMD slides:
http://img266.imageshack.us/img266/6...celona1fa6.jpg
http://img255.imageshack.us/img255/7...celona2gm6.jpg
http://img255.imageshack.us/img255/4...celona3gh6.jpg
http://img255.imageshack.us/img255/1...celona4zr0.jpg
http://img253.imageshack.us/img253/7...celona5uu5.jpg
http://img253.imageshack.us/img253/8...celona6gs8.jpg

In the list there is data from other sources also, that I have collected from internet and saved on HD. If it is very important for someone, I can find out the links of the sources and post here. My goal is to make a list of K8L(K10) vs K8 differences and improvements. Thats how people will be able to find all informations about K8L(K10) Macro/micro architecture on one place, instead googling and opening tens of useless documents. So, if anyone can add something to the list, will be appreciated.

Thank you.

Quote:

---

Originally Posted by gOJDO

@oldblue
Most of Dresdenboy's list at SI is from AMD slides:

---

I'm not questioning the veracity of most of this information, and I think this list is useful. I hope that as people update it, they list their sources. Hyperlinking each entry would help with this. Otherwise it will become difficult to separate internet rumor from AMD-supplied information.

But most of your list was clearly copied and pasted from Dresdenboy's list, and I think he should get some credit for that.

Quote:

---

Originally Posted by oldblue

I'm not questioning the veracity of most of this information, and I think this list is useful. I hope that as people update it, they list their sources. Hyperlinking each entry would help with this. Otherwise it will become difficult to separate internet rumor from AMD-supplied information.

But most of your list was clearly copied and pasted from Dresdenboy's list, and I think he should get some credit for that.

---

Yes, I copy/pasted from there, rearranged the list and added other info.
Anyway, 100% of what I copy pasted from Dresdenboy's list is copy pasted from the AMD slides that I already have on my HD. Also, there is some info from metro.cl from chilehardware, hypertransport.org, other AMD slides. So, credits goes to all of them.

wow sounds like a monster.

good post.

yeah gOJDO thanks for the effort :thumbsup: :)

Thank you, Carfax. I'm still learning all this stuff. But it does look good.
Stephen said K10 is about 10% faster than Core2 in general use, that's what I was specting.

Internaly both look quite similar. 4x DP FLOP / 2x 128 bit SSE per cycle, etc. They are very diferent design but do the same work. Then the IMC will it's job. Point for AMD.
For quad-core parts the monolitic design plus the L3 cache may speed things up significantly. Another point for AMD.
And 2P, 4P or even 8P (fully connected by 8 bit HTT3.0 links) systems will perform so strong, that Sun might go back in it's Intel partnership. :D

But Intel has better manufaturing process, it may rule on desktop systems due to higher overclocking rates, and in 2P servers due to lower power consumption.

gOJDO, can you tell me where to get that presentation ?

Quote:

---

Originally Posted by informal

Oldblue is right,the majority of this info was posted by DDB on SI board,then he linked it to his post at Ace's ,which gojdo copy/pasted here without crediting DDB.
Oh well..

---

He should not need to, as DDB is merely posting second-hand information.

EDIT, if DDB wrote an article about it without posting slides, then yes, Gojdo should credit him. No one but AMD should receive credit for posting slides online.

Quote:

---

Originally Posted by vitaminc

He should not need to, as DDB is merely posting second-hand information.

EDIT, if DDB wrote an article about it without posting slides, then yes, Gojdo should credit him. No one but AMD should receive credit for posting slides online.

---

To be clear, Dresdenboy did not post slides. He compiled and posted this list yesterday:

Quote:

---

Originally Posted by DDB_WO

* Comprehensive Upgrades for SSE

- Dual 128-bit SSE dataflow
- Up to 4 dual precision FP OPS/cycle
- Dual 128-bit loads per cycle
- Can perform SSE MOVs in the FP “store” pipe
- Execute two generic SSE ops + SSE MOV each cycle (+ two 128-bit SSE loads)
- FP Scheduler can hold 36 Dedicated x 128-bit ops
- SSE Unaligned Load-Execute mode

Remove alignment requirements for SSE ld-op instructions
Eliminate awkward pairs of separate load and compute instructions
To improve instruction packing and decoding efficiency

* Advanced branch prediction

- Dedicated 512-entry Indirect Predictor
- Double return stacksize
- More branch history bits and improved branch hashing

* 32B instruction fetch

- Benefits integer code too
- Reduced split-fetch instruction cases

* Sideband Stack Optimizer

- Perform stack adjustments for PUSH/POP operations “on the side”
- Stack adjustments don’t occupy functional unit bandwidth
- Breaks serial dependence chains for consecutive PUSH/POPs

* Out-of-order load execution

- New technology allows load instructions to bypass:

Other loads
Other stores which are known not to alias with the load

- Significantly mitigates L2 cache latency

* TLB Optimisations

- Support for 1G pages
- 48bit physical address
- Larger TLBs key for:

Virtualized workloads
Large-footprint databases and
transaction processing

- DTLB:

Fully-associative 48-way TLB (4K, 2M, 1G)
Backed by L2 TLBs: 512 x 4K, 128 x 2M

- ITLB:

16 x 2M entries

* Data-dependent divide latency
* More Fastpath instructions

– CALL and RET-Imm instructions
– Data movement between FP & INT

* Bit Manipulation extensions

- LZCNT/POPCNT

* SSE extensions

- EXTRQ/INSERTQ,
- MOVNTSD/MOVNTSS

* Independent DRAM controllers

- Concurrency
- More DRAM banks reduces page conflicts
- Longer burst length improves command efficiency

* Optimized DRAM paging

- Increase page hits
- Decrease page conflicts

* History-based pattern predictor
* Re-architect NB for higher BW

- Increase buffer sizes
- Optimize schedulers
- Ready to support future DRAM technologies

* Write bursting

- Minimize Rd/Wr Turnaround

* DRAM prefetcher

- Track positive and negative, unit and non-unit strides
- Dedicated buffer for prefetched data
- Aggressively fill idle DRAM cycles

* Core prefetchers

- DC Prefetcher fills directly to L1 Cache
- IC Prefetcher more flexible

2 outstanding requests to any address

* Shared L3

- Victim-cache architecture maximizes efficiency of cache hierarchy
- Fills from L3 leave likely shared lines in the L3
- Sharing-aware replacement policy

---

I stay with my prediction.

Per core at the same clockspeed, for real-world integer programs that are not unrealistically memory starved (i.e. no SuperPi, and not using decompression as benchmark) this will bring 5%. Let's take compilation (of C/C++ programs) as the benchmark when we want to check on this later.

Quote:

---

Originally Posted by doompc

gOJDO, can you tell me where to get that presentation ?

---

I don't remeber the site(korean) and I can't find them googling, but I'll UL the rest of the slide images:

http://img510.imageshack.us/img510/7...celona8ct1.jpg
http://img510.imageshack.us/img510/4...celona9qh6.jpg
http://img504.imageshack.us/img504/2...elona11kx2.jpg
http://img528.imageshack.us/img528/1...elona10wx5.jpg
http://img528.imageshack.us/img528/5...elona12uh3.jpg
http://img528.imageshack.us/img528/2...elona13cn9.jpg
http://img521.imageshack.us/img521/1...elona14zv5.jpg


@oldblue
As you can notice, every word from DDB list is copy-pasted from the AMD slides and I have the slides long time ago before yesterday. DDB just gave me the idea to make a list(like he did) with all the informations about K8L(K10) improvements, but I didn't found any additional info than the info I already had, form his list.

Quote:

---

Originally Posted by doompc

gOJDO, can you tell me where to get that presentation ?

---

Quote:

---

Originally Posted by gOJDO

I don't remeber the site(korean) and I can't find them googling

---

I believe they're from a Japanese site. Hiroshige Goto posted the slides last October.

http://img510.imageshack.us/img510/7...celona8ct1.jpg

Any details about this ?
Dual Independent Single Channel Memory Controllers would be great, but I don't think so...

"Independant MCs" means QC parts have one 64bit controller dedicated for each pair of cores. K8 ofcourse has equally two 64bit'ers but the difference is they'r in ganged mode.

2x128bit can't naturally be done without adding about a hundred extra socket pins.

Quote:

---

Originally Posted by largon

"Independant MCs" means QC parts have one 64bit controller dedicated for each pair of cores. K8 ofcourse has equally two 64bit'ers but the difference is they'r in ganged mode.

2x128bit can't naturally be done without adding about a hundred extra socket pins.

---

actually there are more than plenty of pins for that on Socket F but not sufficient on socket AM2 ;)

Quote:

---

Originally Posted by brentpresley

Where this CPU REALLY has potential to shine are multimedia apps that have been optimized for SSE/2/3/4a and have predictable memory access patterns. The L3 cache in that situation, on top of the double-wide SSE units should make this chip untouchable for C2D in encoding/encrypting/etc.

On the flipside, since K8L/K10 is still a 3-decoder core that doesn't look like it implements anything similar to micro-ops fusion, C2D will probably maintain a slim lead there (2-5% or so in 32-bit code, and that may be reversed in 64-bit code since C2D doesn't implement fusion in 64-bit).

Just speculation on my part. Flame me if you will.

---

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:

Thanks for all the hype, guys ;)

My original source were these slides:
http://public.cranfield.ac.uk/SOE_te...don_071206.pdf
They also contain a lot of other interesting stuff.

I compiled this list to answer a posting from someone, who seems to deny any IPC improvements in K10's core except for some FP related stuff. Throwing a huge list at him seemed to be a better argument than just saying ("It has improvements"). This was a good motivation :D And don't forget my comment:

Quote:

---

Originally Posted by DDB

However, regarding IPC.. Have a look at this list and think about the design efforts and if they'd be worth it, if most of the more general changes wouldn't cause IPC improvements of ~1% or more per core modification?

---

This thought was my reason for assuming, that we'll see significant IPC improvements on any code (INT/FP) over K8.

The L1 sizes are still 64kB as confirmed by AMD:

Quote:

---

Originally Posted by Johan@aceshardware

At our last phone call, Damon Muzny repeated this at least 3 times that the figure with Data cache might have confused a lot of people: but the L1 is still 64KB D + 64 KB I, just like it was before.

---

http://aceshardware.com/forums/read_...8309&forumid=1
This has been discussed months ago and BTW the die plot's have never shown smaller L1 caches.

The clock gating stuff now officially confirmed by AMD first appeared in Yager's heavily critized article on computerworld. My take on this was:

Quote:

---

Originally Posted by DDB

First I didn't read the full article (because it sounded like simple PR), but then I saw this sentence quoted above. If that is true, then (and probably together with an Intelish typ. TDP) AMD would really yield more sellable parts and could maybe even offer HE variants right from start.

I wrote about AMD's patents regarding such fine grained power saving a while ago. Interestingly the 2 inventors (Filippo, Pickett) involved in power saving stuff are well known names on many other patents (like Pat. No. 7,165,167, where you'll find both together with Ben "Barcelona Man" Sander), which fit nicely to Barcelona's new features. So for the interested ones:

Pat. No. 6,826,704 - Microprocessor employing a performance throttling mechanism for power management
Pat. No. 6,983,389 - Clock control of functional units in an integrated circuit based on monitoring unit signals to predict inactivity
Pat. No. 6,976,182 - Apparatus and method for decreasing power consumption in an integrated circuit

And again the filing dates of most of these patents (2002/2003) should make clear, that Barcelona is not an answer to Intels new architecture. People knowing the design lifecycle of such a highly integrated CPU never thought so.

---

(http://www.siliconinvestor.com/readm...msgid=23261707)

If AMD is really going to use Intelish TDP numbers (based on measurements while running some "power virus" software) and as it has these HW based p-state transitions, clock gating and maybe some form throttling, it may increase Barcelona's yield, because they can sell parts, which'll never break the given TDP, while without this power related stuff would have exceeded the currently used TDP "thermal envelope".

AMD's patents show a lot of interesting details regarding K10, like clock gating, details of a 128 bit wide operating FPU (Pat. No. 6,944,744), the new memory controller (e.g. patents about reducing page conflicts), zonal monitoring of temperature on the die, HW based power state transitions, thermal throttling etc.

So it's never bad to have a look at them. BTW, some of the patents by guys, who seem to be K10 architects, are trace cache related.

@Dresdenboy
:toast: Thanks for your input and info!
I am trying to make a good collection of informations about K8L(K10):
http://forumz.tomshardware.com/hardw...501779#1501779

I will appreciate if you can add something to the list. ;)

Dresdenboy.. plz stay here =)

Must check out:

http://translate.google.com/translat...%3Den%26sa%3DG

Some more thoughts on IPC:

What this big list shows, are things, we'll see coming with K10. But it's difficult to estimate the effect on different kinds code, especially if the situation on K8 wasn't close to being optimal. For example the K8 FPU can't do 128 bit SSE loads in FMUL or FADD unit, while it can do 64 bit loads in any unit. This limited capability turned out to be an important bottleneck for Prime95 code (see http://mersenneforum.org/showthread.php?t=1072 and http://mersenneforum.org/showthread.php?t=2362#15).

I'm not sure right now, if the FP scheduler can select any MacroOp from any lane to send them to the subunits or if there is kind of a link to certain subunits like it happens for the INT units. This could mean, that the decoders produce triples of MacroOps with only one slot used (e.g. if the ops can only go to FMISC). This would leave a lot of FP scheduler slots unused.

However - if such limitations (one is also, that SSE register moves were only handled by FADD and FMUL) are no more present, the effect on performance could theoretically reach levels above that of simply widened units and datapaths.

And we should also not forget, that 3 MacroOps in K8 already mean up to 6 µOps (practically up to 3 ALU/FP ops and 2 AGU ops). So what seems to be a max of 3 µOps is actually a max of 5 µOps (even 6 would be possible, but this might not be reachable). This might lead to cases (e.g. complex address ops with more than one dependency, multiple complex ops or RMW-ops), where the decoding rate of K8 and K8L might be on par or even higher than that of C2D.

Recently I found a free cycle exact µArchitecture simulator (http://www.ptlsim.org/), which has been used to model modern CPUs (even with stuff like OOO loads). If time permits, I could try to apply the known architectural changes of K10 to their already existing K8 like setup, enable stuff like OOO loads and L3 cache and see, how it fares. This might be more of an accurate estimate, than anything else based on our personal theories :)

Thanks for the nice bits of info DDB :toast:

Thanks for the post and the link Dresdenboy :toast:

Thanks for your thoughts DDB and I can't wait for analysis using PTLSIM...
Hope you will have time shortly to play with it!
PS. CeBIT is coming quickly and we might find out some real performance numbers then.

Thanks Dresdenboy. You're probably already aware of this, but Agner Fog's optimization manuals include an independent analysis of the K8 microarchitecture and he suggests some bottlenecks. It's not from AMD, so there might be some mistakes, but it might be a good place to start. It's a pretty good read for anyone interested in the subject.

It would be interesting to see how these bottlenecks are addressed in Barcelona.

Quote:

---

Originally Posted by oldblue

Thanks Dresdenboy. You're probably already aware of this, but Agner Fog's optimization manuals include an independent analysis of the K8 microarchitecture and he suggests some bottlenecks. It's not from AMD, so there might be some mistakes, but it might be a good place to start. It's a pretty good read for anyone interested in the subject.

It would be interesting to see how these bottlenecks are addressed in Barcelona.

---

Great (but loooong) read! Thanks OLDBLUE! It seems that K10 is addressing most of bottlenecks of K8 micro architecture (from what we know now). It is possible that AMD made more mini improvements we don't know about yet.

Only time will tell :)

Quote:

---

Originally Posted by Lightman

Great (but loooong) read! Thanks OLDBLUE! It seems that K10 is addressing most of bottlenecks of K8 micro architecture (from what we know now). It is possible that AMD made more mini improvements we don't know about yet.

Only time will tell :)

---

of course, because it would be illogical to leave problems and not improve

Quote:

---

Originally Posted by oldblue

Thanks Dresdenboy. You're probably already aware of this, but Agner Fog's optimization manuals include an independent analysis of the K8 microarchitecture and he suggests some bottlenecks. It's not from AMD, so there might be some mistakes, but it might be a good place to start. It's a pretty good read for anyone interested in the subject.

It would be interesting to see how these bottlenecks are addressed in Barcelona.

---

Thanks. I was aware of these documents and even just had a look at them a day before you posted this link here ;)

Unfortunately these manuals based on experiments and collected information were not available, when George Woltman and I tried to find the reasons for the performance of Prime95 on K8 in 2003/04. At least we found some kinds of behaviour which fits nicely to what is described in that manual.

I think, that some of the bottlenecks just derived from the special handling of double decoded SSE ops, which shouldn't happen anymore with dedicated 128 bit µOps. Just think of a MOVAPD, which fills 2 consecutive FMISC slots in two groups of 3 MacroOps. An SSE instruction, which follows this MOVAPD, might not fill the 4 free slots in these groups optimally, because it's behind in program order. Such situations might be eased up in Barcelona. That's, where I think Barcelona will win some performance not only by increasing throughput, but also by better handling of the 128 bit ops.

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:

---

Uhm.. Games prefer integer ops? Are you serious.. All 3d Games REQUIRE FP ops.. You know how inaccurate the 3d engines would be if they used Int ops. I think you should go and check up on your game engine specifics.. This has to be one of the most uninformed posts I have ever read.

Quote:

---

Originally Posted by Wrench

Uhm.. Games prefer integer ops? Are you serious.. All 3d Games REQUIRE FP ops.. You know how inaccurate the 3d engines would be if they used Int ops. I think you should go and check up on your game engine specifics.. This has to be one of the most uninformed posts I have ever read.

---

Yes, all games require "FP ops," and the GRAPHICS CARD handles the vast majority of those ops :rolleyes:

Before you criticize my posts, you should get yourself a clue.. :p:

Quote:

---

Originally Posted by Carfax

Yes, all games require "FP ops," and the GRAPHICS CARD handles the vast majority of those ops :rolleyes:

Before you criticize my posts, you should get yourself a clue.. :p:

---

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 don't know about you but I did a bit of OpenGL programming and you can setup a cubic enviornment easily with Integer but as soon as you get into tris its imposible to have a cohesive geometry with integer calculations. Cubes have straight lines so its easy enough to figure that out but how do you figure out lets say the edges of triangle with out the pythagorean theorem, sure their might be a case where you get lucky to figure out one side with ints but thats gone be damn hard.

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.

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.