Dresdenboys' blog: AMD Bulldozer - Patent based research

[Chumbucket843]

I don't think that's accurate. Since CMT isn't something they're likely to just tack on at the end and AMD is likely to be experimenting with pieces on silicon at this point, I think it's rather more likely that it isn't just some neat concept paper. At the very least, its physical implementation has probably been designed.

i would not make any claims about performance based only on patents even though i am still excited about bulldozer. sure they probably changed the architecture (more specifically out of order engine) for CMT but only AMD knows how effective it is. its a little annoying to see the blogs and threads on bulldozer discredit intel's architectures. they either do it wrong or amd does it better.

AMD didn't choose multi-threading like Intel did for their Pentium 4 in the Athlon 64 and their realized that it is a mistake. So they won't do this again!!!

prescott needed SMT badly. now with more multithreaded apps and >4 cores it provides a benefit to all cpu's.

[hlopek]

Bulldozer will be made up in a similar way a new arc. but a base has to be there like Pentium was for the Nehalem, maybe bulldozer will be based on Am386 or K6, both are very good arc's.

Am386 & K6 were really good at their time and better solution than Intel's previous generation CPUs that were design to compete with. Let them rest in peace. I'd say it would be extremely wrong if AMD would now reject some 15yrs of K7 development and good ooo architecture in favor of some io CPUs
If AMD could develop ooo engine by itself out of nothing in the K6-2/K6-3 time they wouldn't need reassembly Alpha to produce first real ooo chip four years after Intel's Pentium Pro. So it would be lose lose situation in times when AMD looses it's competitiveness in high-end desktop/workstation market segment.

Bulldozer won't have the same underlying Kx architecture and will be design around totally different concept(in order to achieve maximum throughput both in int and fp workloads).The only thing that may resemble the Kx will be HyperTransport in the uncore part of the chip and FP/SSE in the core part.The latter(SSE units) will in reality still be 2x + faster than in the K10.5 due to AVX 256bit support and possibly other improvements.

Yes but that's still OneCore that has 2x 128b wide ALU and 256b FPU that they now call X2? It's pure propaganda to claim it X8 when trully capable octa core Sandy Bridge CPU came out.With same AVX capability but inside real core not shared over Unified-X2-Core

Could you explain that HT connections in UnCore part, so does that mean that L3 and every "X2-core" itself will be connected by some HT like bus? And not with truly 64 byte wide bus as it has been rule for all L1/L2 caches from first Athlons with on die L2 cache. L3 also use same 64 byte width bus.

doubt that we will see an amd ddr4 board on ddr4 launch... amd will probably wait till ddr4 has matured a bit

like they did with ddr3 and not sure about ddr2 on how it happened since i just got introduced to oc'ing

You could be wrong about that DDR4 support cause they did support DDR3 already in 2007 with Barcelona/Agena just they didn't want to pust it out cause of DDR3 prices, availability and possibly because TLB bug With DDr2 suport is even more weird story cause they done it 2006 cause they didn't desperatly needed bandwidth as Intel NetBurst architecture and their QBP did.

In the time of SDRAM/DDR SDRAM transtion AMD was firt that was introduced DDR chipset for their Athlon (Thunderbird/Spitfire) chips for socket A.

So they could done it once again with DDR4 if they need it for any stupidest reason as marketing bragging rights Ever since K7 their CPUs need as low latency as they could get and every new DDR iteration increases latency further. So yo do the math why they always stalling with newer emory type adoption

Maybe they'll use DDR3-DDR4 mixup for some Fusion chips cause graphics always has need for more bandwith. Or they even might introduce their Fermi/Larabee GPGPU sharing same "future AMD LGA" socket as CPU. So there's even a slight chance that they adopt first DDR4 for a reason

[hlopek]

AMD is on track to maintain tempo of new uArch every four years... K7->1999, K8-> 2003, K10->2007, Bulldozer (K11) -> 2011

There's no such processor family as K10 & K11 And you just named families. Like anything hasn't been improved between K7->Athlon->Athlon XP or between Athlon64 s939->Athlon64 sAM2 ??

K7 was huge outburst in 1999 with it's first superscalar CPU. And K8 with IMC (integrated memory controller) was also huge improvement upon K7 architecture in 2003. While extra 8 regs, 64-bit processor and larger 40-bit memory address space (up to 1TB) was only useful in server segment. (Not to be confused, that enhancements really prolong x86 life) And in fact that was a market goal they want touch with their K8 in 2003.

K8L was a time needed refreshment (and time buying ) of aging K8 architecture and beyond UnCore wise copycat from "future" Nehalems, and necessity for implementing huge L3 cache. It also further expands memory address space to 48-bit and improves ITLB for future apps testing in some supercomputers. And that's all the novelties it brought to the world.
On desktop market K8L finally widen SSE cruncher to 128-bit width so that we could finally execute whole SSE instruction in single pass on their dummy FPU that wasn't brought any significant improvement in K8 over K7-Athlon XP predecessor. First K7 had only MMX beyond great K6-3 3dNow! that was newer widely adopted, K7-Palomino (Athlon XP @180nm) brought us SSE capabilities but only on already present 64-bit wide MMX, XMM unit. So until K8L nothing has improved inside Athlon core in 5 yrs, except SSE2 and SSE3 code awareness and already mentioned K7-K8 transition on 64-bit.

K8/K8L share same reorder strategy as K7 and it was relatively 5-10% worse over P6 unified reservation station which 20-entry only (preserves die space, have higher utilization but it's UNIFIED and doesnt allow of too much cache misses as K7 does and that was mostly resolved with Core architecture ROB awareness of memory disambiguation and 32-entry wide reservation, +60%).

Hopefully that ALU scheduler unification which Bulldozer should bring, and which is needed for reduce of wasting die space and power consumption, won't be as much of the mess as K6-2/K6-3 were with their virtualized ooo/parallel engine on what was essentially in-order cpu. Well Bulldozer is at least based on Alpha/K7 work so it should be better cause they should have enormous experience based on last 10 years r&d.

But still simpler and more utilized reservation station, like that P6 (1995) first brought us, looks much more appealing because it could be further widen at lower power and die complexity expense. And at the same tame it brings more performance gains cause it's tidier approach than this in K7/K8/K8L distributed schedulers.

Well, at least now AMD has unified ALU scheduler as it had FP unified scheduler since the beginnings. And now, that 2xALU schedulers with 1xFP scheduler is considered a X2-core. It's 33% reduction in ALU scheduler complexity and there's possibility to further widen it to improve that underlying 2 ALU/AGU dependencies, but at least now 2x ex-separate 8-entry ALU scheduler became one larger 16-entry wide at zero expense. And they also reduce dependent ALUs/AGUs, from three in K7-K8L generation, to only two making some space for integrating 4 ALUs/AGUs in X2-core.
So all that should considerably reduce power consumption from K7-K8L architecture. But it should be better if True OneCore itself has unified scheduler, but that would need extreme r&d expense or they just want make us to believe that, and i don't believe that inte has exclusivity on unified scheduler?! Well in case of unified scheduler they need SMP also instead CMP and couldn't conveniently claim what use to be OneCore in K7->K8L as brand new X2-core just by adding one extra ALU/AGU and unifing K8L 2x 128bit FP units into 256-bit wide. It's certainly looks more flexible than Core architecture is, but they misleading us once again that something that's in fact OneCore by marketing it as X2-core!!

And hopefully they brought us quad channel IMC at desktop boards with 8 memory slots and not only reserve it for workstation/server market. This approach simply needs it

*Cause in case they stick to individual FP/ decoders and decide to widen them (which is dead beat as many saw even before Intel introduce Willamette cause for 3 instructions as Athlon has it is already enormous power hungry beast an main culprit to further power scalbility

what's really encouraging is the fact that even in these hard times

Not not really more of disappointing i'd say i case of K8L advancements. Let' hope that Bulldozer will redeem from that K7-K8-K8L inheritance.

basically all that Bulldozer needs now is 32nm tech verification! AMD isn't going to make another K10 mistake and go with old process and new architecture.
We can see now that what K10 needed was 45nm tech to show it's true value. If only IBM has perfected SOI on Immersed 45nm tech when was promised... definitely Sony and AMD suffered most 'cos of that delay.

What you meant by it? K8L (so called K10) was built onto proven 65nm process! They proof it by K8 sAM2 (so called K9) 90nm dumb shrinks to 65nm and with some twiddling on memory controller making Athlon64 capable of running at "half-multis", remember.

K8L didn't suffer at all from it's 65nm :grin: but from serious TLB bugs in it's first incarnation (Agena B2) which really put dark shadows onto AMD cause if you were Opteron customer you get replacement with TLB bugfix (Agena B3) for free but not if Phenom buyer. It's fraudulent policy if you ask me. And it also heavily suffered from lack of r&d funds when AMD decided to poor down all their cash into devious ATi.
It wasn't really invested much into Phenom after disappointing TLB and leaving all needed bug cleaning job for 45nm node shrink so they could make good sale of it. Except that bug wiping and larger 50% more associative cache (6MB 48-way L3 vs. 2MB 32-way L3) 45nm didn't brought nothing new. Do you thing that Phenom II would look so appealing if they didn't brought roughly 40% performance jumps over Phenom and at the same thermal envelope? And for that they didn't need nor 45nm nor 6MB of cache for only quad-core in case they done job properly first time @65nm. Then we'd probably look as much as some 20% performance gain in best case and beyond integrated (not really needed for CPu but good for platform deployment) DDR3 controller there would be much lower hype about Phenom II than it was in 2009.

with 32nm tech and state of things in GloFo, story with 32nm tech will be completely different, and AMD could start verification of Bulldozer uArch with first tape-out of 32nm wafers in summer 2010...

With nothing more than core rearranging K8L X4 (Phenom II X4) and claiming it as Bulldozer X8, and with all that power wise improvements they try to introduce inside a core, i don't think there's really necessity for 32nm. Except for higher scaling, lower power consumption and better yielding--more profit they could release commercial product @45nm if they needed. But there's no rush for AMD, and they certainly don't want to show us supossedly yet again poor scaling of Bulldozer chip as Agena did @65nm. I'd with all tweaks expect 140W OC @45nm to be roughly the same as it was for Phenom II ~4.2GHz, and for 32nm atleast ~5.5GHz OC on air. But somehow prototyped Bulldozer @45nm would be yet another power hungry under performing beast as it was Phenom (Agena @65nm). We'll it'll be better if they really good spent that time needed for 32nm SOI High-K verification and cleanup bugs for introduction. They certainly don't need yet another TLB like affair.

it depends who you're and what you do... for some people out there only a year

Unfortunately we all cant be fud journalist like you. Since fudders like you occupy "IT sites" some years back we more and more miss some accurate infos and all "reviews" looks like different 3Dmark/SuperPi benches usually not even concluded on same platform but put into same graph comparison

[fellix_bg]

"K8L" was the code name for the low-power K8-based Turion processors, not the native quad-core Barcelona architecture.

[ajaidev]

To put things into prospective i made these. The BD modules are suppose to perform ~80-90% of a dual core cpu lets say a deneb based , so a dual module BD will come close to a deneb quad core and a quad module based BD will come close to a 8 core based deneb. Now as things stand a x5550 ~ x4 2435, this means AMD has to give 6 core to achieve what intel does with 4. In BD terms, you will need a three bulldozer modules to come close to a Nehalem based cpu but what we have seen with westmere "hex core" is great and i expect sandy bridge to only improve in performance. So much so that i expect only a four module bulldozer maybe able to compete with a four core sandy bridge.





If Intel releases a 6 core based sandy bridge, AMD will have to release a 6 module based cpu IMO.

[xVeinx]

To put things into prospective i made these. The BD modules are suppose to perform ~80-90% of a dual core cpu lets say a deneb based , so a dual module BD will come close to a deneb quad core and a quad module based BD will come close to a 8 core based deneb. Now as things stand a x5550 ~ x4 2435, this means AMD has to give 6 core to achieve what intel does with 4. In BD terms, you will need a three bulldozer modules to come close to a Nehalem based cpu but what we have seen with westmere "hex core" is great and i expect sandy bridge to only improve in performance. So much so that i expect only a four module bulldozer maybe able to compete with a four core sandy bridge.

If Intel releases a 6 core based sandy bridge, AMD will have to release a 6 module based cpu IMO.

It doesn't work like that. The architecture is completely different, with a potentially decent boost in IPC, so any comparison to deneb's performance makes little sense. 80-90% of another core means that they save a bit of space by using the modules, but maintain close to 90% of the performance of 2 cores in multi-threaded applications, whatever that level of performance will be. Frankly, I'd be wary of comparing Sandy Bridge and Bulldozer, as there are some decent architectural changes on the horizon for both camps. It really is a shot in the dark.

I have a couple of questions, which might be a little naive-I'm not terribly knowledgeable about such things here . It would appear that there is a boost in single threaded performance that takes place by using the modules simultaneously, and I'm curious as to how that will play out in multi-tasking, as to how that might balance when you have multiple single threaded processes (or even a single threaded app running alongside a multi-threaded app).
Secondly, part of the architecture change with bulldozer is a change in the efficiency of the processor. There are some definite changes taking place in the FP unit, but I'm not sure how much this will end up being when it comes to actual performance. Is the boost in Floating point calculations going to come mostly due to a more efficient use of the current units, or due to an actual boost in IPC?

[ajaidev]

It doesn't work like that. The architecture is completely different, with a potentially decent boost in IPC, so any comparison to deneb's performance makes little sense. 80-90% of another core means that they save a bit of space by using the modules, but maintain close to 90% of the performance of 2 cores in multi-threaded applications, whatever that level of performance will be. Frankly, I'd be wary of comparing Sandy Bridge and Bulldozer, as there are some decent architectural changes on the horizon for both camps. It really is a shot in the dark.

I have a couple of questions, which might be a little naive-I'm not terribly knowledgeable about such things here . It would appear that there is a boost in single threaded performance that takes place by using the modules simultaneously, and I'm curious as to how that will play out in multi-tasking, as to how that might balance when you have multiple single threaded processes (or even a single threaded app running alongside a multi-threaded app).
Secondly, part of the architecture change with bulldozer is a change in the efficiency of the processor. There are some definite changes taking place in the FP unit, but I'm not sure how much this will end up being when it comes to actual performance. Is the boost in Floating point calculations going to come mostly due to a more efficient use of the current units, or due to an actual boost in IPC?

BD is a new architecture, Sandy bridge is not its a evolution. Yes this is a shoot in the dark but its hardly likely that a single BD module can overtake a dual core K10.5 in multi threaded tasks, thus the 80-90% "CMT vs true dual core argument"

You cant use modules simultaneously for single thread, for two threads the whole module can be used and these two threads will share the common FP unit. The scheduler will take care of multi threaded and single threaded division.

BD will provide (4x 64-bit FP MUL and ADD)/clock and Nehalem gives (4x 64-bit FP MUL or ADD)/clock

[AliG]

BD is a new architecture, Sandy bridge is not its a evolution. Yes this is a shoot in the dark but its hardly likely that a single BD module can overtake a dual core K10.5 in multi threaded tasks, thus the 80-90% "CMT vs true dual core argument"

You cant use modules simultaneously for single thread, for two threads the whole module can be used and these two threads will share the common FP unit. The scheduler will take care of multi threaded and single threaded division.

BD will provide (4x 64-bit FP MUL and ADD)/clock and Nehalem gives (4x 64-bit FP MUL or ADD)/clock

I disagree, you're logic is missing one very key fact. Integer performance is far more important than FP for most applications, if it wasn't everyone would be using k10.5s instead of core 2 quads (nehalem is a different beast).

Each bulldozer modules has 2 integer "cores" that are 4 issue. k10.5 has 3 issue integer. That makes a world of a difference, so bulldozer should have a sizeable increase in single threaded performance, I believe that latest number was something around ~35%. If you take into account that increase, then the 80% increase from the second module will surpass the efficiency of two physical k10.5 cores (.8*1.35+1.35=2.43). Even if you took 20% increase, which is probably more realistic to be honest, you still get .8*1.2+1.2=2.16, thus on average 1 bulldozer module will not only be 20% faster than 2 k10.5 cores for single threaded tasks, but also 8% faster for multithreaded. If you expand that to 2 modules, then you see an average of 16% increase over a k10.5 quadcore for multithreaded tasks, which quite frankly is a very nice increase.

It's simple math really. This is the same reason why core 2 duo was still faster than k10, even though k10 spanked it in FP. k10 had only 3 issue integer logic to core 2's 4.

[informal]

I disagree, you're logic is missing one very key fact. Integer performance is far more important than FP for most applications, if it wasn't everyone would be using k10.5s instead of core 2 quads (nehalem is a different beast).

Each bulldozer modules has 2 integer "cores" that are 4 issue. k10.5 has 3 issue integer. That makes a world of a difference, so bulldozer should have a sizeable increase in single threaded performance, I believe that latest number was something around ~35%. If you take into account that increase, then the 80% increase from the second module will surpass the efficiency of two physical k10.5 cores (.8*1.35+1.35=2.43). Even if you took 20% increase, which is probably more realistic to be honest, you still get .8*1.2+1.2=2.16, thus on average 1 bulldozer module will not only be 20% faster than 2 k10.5 cores for single threaded tasks, but also 8% faster for multithreaded. If you expand that to 2 modules, then you see an average of 16% increase over a k10.5 quadcore for multithreaded tasks, which quite frankly is a very nice increase.

It's simple math really. This is the same reason why core 2 duo was still faster than k10, even though k10 spanked it in FP. k10 had only 3 issue integer logic to core 2's 4.

AliG is right... One BD module will totally SMOKE a dual core K10.5 ,it's not even funny...

[Manicdan]

im scared if AMD totally stomps intel in the next few years, cause that means they can charge alot for these chips, and then i wont be able to afford it...

[god_43]

im scared if AMD totally stomps intel in the next few years, cause that means they can charge alot for these chips, and then i wont be able to afford it...

ya i have the same worry....but my desire for them to win; rises above all else. what i don't get is - obviously this is not the complete arch spec.

[Xoulz]

it will for sure have i7 (more probably) power. but i think it is really up in the air. from what i understand, this design is very ....different/new, because of this; it is hard to tell what type of power it will yield? any of the gurus care to correct me?

Anything that is orderly and computational, will get crushed by this chip, period!

[Xoulz]

It doesn't work like that. The architecture is completely different, with a potentially decent boost in IPC, so any comparison to deneb's performance makes little sense. 80-90% of another core means that they save a bit of space by using the modules, but maintain close to 90% of the performance of 2 cores in multi-threaded applications, whatever that level of performance will be. Frankly, I'd be wary of comparing Sandy Bridge and Bulldozer, as there are some decent architectural changes on the horizon for both camps. It really is a shot in the dark.

I have a couple of questions, which might be a little naive-I'm not terribly knowledgeable about such things here . It would appear that there is a boost in single threaded performance that takes place by using the modules simultaneously, and I'm curious as to how that will play out in multi-tasking, as to how that might balance when you have multiple single threaded processes (or even a single threaded app running alongside a multi-threaded app).
Secondly, part of the architecture change with bulldozer is a change in the efficiency of the processor. There are some definite changes taking place in the FP unit, but I'm not sure how much this will end up being when it comes to actual performance. Is the boost in Floating point calculations going to come mostly due to a more efficient use of the current units, or due to an actual boost in IPC?

Many of the patents apply to the IPC, didn't they? This going to be a Cruncher?

[god_43]

ooooo nice update http://citavia.blog.de/

[haylui]

ooooo nice update http://citavia.blog.de/

finally there is update on BD....

[savantu]

AliG is right... One BD module will totally SMOKE a dual core K10.5 ,it's not even funny...

And you know that how ??

[AliG]

And you know that how ??

Simple math. I just explained it.

How stupid do you think AMD engineers would have to be to design a product that's less efficient than the previous one in our current market? Today everything in servers is about performance/watt, they'd have to be brain dead to implement an architecture that requires more power to accomplish the same task.

Seriously, I don't understand why some people think Bulldozer will be slower than k10.5. It's mind boggling that anyone but a troll would try to spread these rumors.

[god_43]

what who said it would be slower? for some reason i am a bit more excited about the core size?

[savantu]

Simple math. I just explained it.

How stupid do you think AMD engineers would have to be to design a product that's less efficient than the previous one in our current market? Today everything in servers is about performance/watt, they'd have to be brain dead to implement an architecture that requires more power to accomplish the same task.

Seriously, I don't understand why some people think Bulldozer will be slower than k10.5. It's mind boggling that anyone but a troll would try to spread these rumors.

Bulldozer looks to be all about through-output oriented.I think it will be weaker in single threaded integer apps than current K10.5s since the INT units were simplified.
For FP, a cluster will beat a single core K10.5 but it will be similar to a double core K10.5

So while in commercial apps it will be great, in desktop ones it won't be any miracle.
That's my 2 cents.

[sdsdv10]

Simple math. I just explained it.

How stupid do you think AMD engineers would have to be to design a product that's less efficient than the previous one in our current market? Today everything in servers is about performance/watt, they'd have to be brain dead to implement an architecture that requires more power to accomplish the same task.

Seriously, I don't understand why some people think Bulldozer will be slower than k10.5. It's mind boggling that anyone but a troll would try to spread these rumors.

So if I understand what your saying, the argument is based on logic not benchmark information. Is this correct?

[qcmadness]

I disagree, you're logic is missing one very key fact. Integer performance is far more important than FP for most applications, if it wasn't everyone would be using k10.5s instead of core 2 quads (nehalem is a different beast).

Each bulldozer modules has 2 integer "cores" that are 4 issue. k10.5 has 3 issue integer. That makes a world of a difference, so bulldozer should have a sizeable increase in single threaded performance, I believe that latest number was something around ~35%. If you take into account that increase, then the 80% increase from the second module will surpass the efficiency of two physical k10.5 cores (.8*1.35+1.35=2.43). Even if you took 20% increase, which is probably more realistic to be honest, you still get .8*1.2+1.2=2.16, thus on average 1 bulldozer module will not only be 20% faster than 2 k10.5 cores for single threaded tasks, but also 8% faster for multithreaded. If you expand that to 2 modules, then you see an average of 16% increase over a k10.5 quadcore for multithreaded tasks, which quite frankly is a very nice increase.

It's simple math really. This is the same reason why core 2 duo was still faster than k10, even though k10 spanked it in FP. k10 had only 3 issue integer logic to core 2's 4.

Long time ago, I think the difference between 3 and 4 issue INT core makes a big difference, but the major difference is about the branch prediction and cache miss.

[Dimitriman]

Bulldozer looks to be all about through-output oriented.I think it will be weaker in single threaded integer apps than current K10.5s since the INT units were simplified.
For FP, a cluster will beat a single core K10.5 but it will be similar to a double core K10.5

So while in commercial apps it will be great, in desktop ones it won't be any miracle.
That's my 2 cents.

You're forgetting one thing...
http://www.xtremesystems.org/forums/...d.php?t=244728

Dynamic Speed Boost Technology will make it to BD. So single threaded apps should be faster as well.

[informal]

Bulldozer won't have weaker single thread performance than 10h... Anyone who believes this needs to rethink. Not only that,but one module will smoke a dual core 10h in throughput and it will do so with less dedicated logic (since many parts are now common for both cores and shared,like the new and much more powerful front end). New cores will also bring new functionality in the form of added instruction sets(AVX+ FMA4) ,more cache,higher working frequencies , uarchitectural improvements etc.

[Hornet331]

Why does all this "hype" reminds me off the first phenom...

Anyway for myself i lean back and see how they really perform when the first confirmed leaks are here. Speculation based on hypothetical situations arn't worth it.

[Particle]

What hype? People are doing their best to say it'll actually be worse. Also remember that K10 was actually a pretty big improvement over K8, before you all forget that.