AMD Zambezi news, info, fans !

[TESKATLIPOKA]

freeloader yet you are still missing 10-20% of performance, thats a lot not to mention what they added was just a second cluster which means only 20% bigger core size without L2 cache, true 2 core without sharing would mean 100% bigger core size on a die.
something like this(without L2 cache)
module without one integer(no sharing, everything can be used by one integer cluster) 15.58mm2
module design 19.4mm2
2 core design 2*15.58mm2=31.16mm2
The performance gain per area increase is worth the performance penalty but comparing it to a regular 8 core is not right in my opinion thanks to the penalty hit.

[freeloader]

freeloader yet you are still missing 10-20% of performance, thats a lot not to mention what they added was just a second cluster which means only 20% bigger core size without L2 cache, true 2 core without sharing would mean 100% bigger core size on a die.
something like this(without L2 cache)
module without one integer(no sharing, everything can be used by one integer cluster) 15.58mm2
module design 19.4mm2
2 core design 2*15.58mm2=31.16mm2
The performance gain per area increase is worth the performance penalty but comparing it to a regular 8 core is not right in my opinion thanks to the penalty hit.

Too me it's no different than Intel classifying it's parts as having 4 cores/8 threads. Bulldozer's turbo function will also make up for some of the 10 to 20% deficiencies in a multi threaded work load, however no processor (that I'm aware of) with a shared cache system can obtain a 100% unified work load over two cores on the same die. (cache latency, cache miss, operating system overhead, etc, etc...)

[informal]

Too me it's no different than Intel classifying it's parts as having 4 cores/8 threads.

The problem with comparing BD and SB with SMT is that in SB's case you have 3 ALU units(and 2 AGU units) in each integer core that are shared by 2 execution threads. The main idea behind this concept is to use pipeline as much as possible and not let those 3 ALU units sit idle (note that those ALUs are both for int and fp!). This happens usually if MT code is not written well enough or the nature of the problem that code is written for is such that it is not parallel-friendly((not able to be broken into smaller amounts of threads and efficiently executed due to many dependencies among the threads).
Now in BD's case,in each module you have a big shared front end and behind it you have 2 execution cores each of which has 2 integer ALUs and 2(+2) floating point execution units. As you can see there is a BIG difference between AMD's "cores" and intel's "threads/cores". Former are real hardware units that are partly dedicated(int) and partly shared(FP) while in later case we have fixed amount of units that are shared equally between 2 threads.