• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.
  • The forums have been upgraded with support for dark mode. By default it will follow the setting on your system/browser. You may override it by scrolling to the end of the page and clicking the gears icon.

AMD FX 8150 with Microsoft KB2592546 Put Through 'Before and After' Patch Tests

Can you say this in English please ? AMD screwed up plane and simple . Sucks to ! We waited 4 years for this ? A launch filled with fluff and when it got into the hands of the consumers it was a total mess . We find out all kinds of things like they did not even know the transistor count ? and that it is out performed by it's older line the Phenom ! REALLY ??? Really you need another hot fix for another CPU line AGAIN AMD ??? WTH ? They put more work and more R&D into there GPU line than there CPU line !

Just throwing it out there Intel has released just as many if not more chips with issues. They had there own TLB bug, P4, bad chipsets, not to mention itanium's fiasco. There is nothing wrong with a hot fix again Intel had had there own batches of them. As of right Bulldozer is the best selling CPU's in AMD's lineup. If they were that shitty everyone would save there couple of bucks and get a Thuban. Get off your Intel high horse and look at the big picture. P4's hyperthreading sucked, but not a single person out there complaining about it on current Intel chips. This is AMD's first new design since K8 which was still heavily K7 based. You might remember Intel's current design is still an end result of a P3. Give AMD a generation to work some kinks out. Hell look at the APU performance jump clock for clock they are doing something right.
 
Its not a true 8 core.

If you are talking about Bulldozer it is a true eight core...

Stop defending it...It has 8 Weak Cores...that have 33% less execution throughput than the competition core

Sandy Bridge has 3 ALUs and 3 AGUs per core(Threads compete for those 3 ALUs and 3 AGUs in Hyperthreading)
Bulldozer has 2 ALUs and 2 AGUs per core(Threads don't compete because there is TWO CORES!)

It's not really hard to notice that it has less execution resources not a longer pipeline

It takes 3 Cycles to do six 64bit executions for Bulldozer where it takes 2 cycles to do six 64bit executions for Sandy Bridge
Bulldozer though with all cores can do sixteen 64bit ALUs calcs. and do sixteen 64bit AGUs calcs. while Sandy Bridge can do twelve 64bit ALUs calcs. and twelve 64bit AGUs calcs.(with hyperthreading same old twelve 64bit ALUs calcs. and twelve 64bit AGUs calcs. no increase sillies)

Bulldozer is meant for Servers that need scalability with thread count...and Bulldozer does scale with thread count
 
Last edited:
If you are talking about Bulldozer it is a true eight core...

bulldozer-overlay.jpg


I count 4 modules (cores)
Stop defending it...It has 8 Weak Cores...that have 33% less execution throughput than the competition core

It also performs similar to the previous generation with the same 3ALU/3AGU as Intel. It has 8 differently structured cores.
Sandy Bridge has 3 ALUs and 3 AGUs per core(Threads compete for those 3 ALUs and 3 AGUs in Hyperthreading)
Bulldozer has 2 ALUs and 2 AGUs per core(Threads don't compete because there is TWO CORES!)

The threads don't compete all hyperthreading does is allow another set of instructions to be sent down the pipeline. It was originally a band-aid for Intel's long pipelined netburst based chips. AMD's new design gave you 2 separate threads something Hyperthreading can never do.
It's not really hard to notice that it has less execution resources not a longer pipeline

Whats either of those have to do with anything. It is still a "short" pipeline CPU in comparison to P4. Due to design it is not comparable to Intel in execution resources.
It takes 3 Cycles to do six 64bit executions for Bulldozer where it takes 2 cycles to do six 64bit executions for Sandy Bridge
Bulldozer though with all cores can do sixteen 64bit ALUs calcs. and do sixteen 64bit AGUs calcs. while Sandy Bridge can do twelve 64bit ALUs calcs. and twelve 64bit AGUs calcs.(with hyperthreading same old twelve 64bit ALUs calcs. and twelve 64bit AGUs calcs. no increase sillies)

Again AMD's K7-K10h chips all offered the same 3/3 setup of calcs and did not offer an improvement except with K7/K8 vs netburst. Core 2 Duo and up when Intel went back to 3/3 were the first competitive offerings. The main reason netburst failed in Intel's eyes was a lack of clock scaling. Original design was said to scale to 8ghz and at that speed its long pipelines and 2/2 design would have held a performance edge.
Bulldozer is meant for Servers that need scalability with thread count...and Bulldozer does scale with thread count

Yup Bulldozer does what it was designed for and in heavily multithreaded apps it holds its own. With future chips offering a more refined design it will likely smoke some multithreading benchmarks. Especially since they already have proven it clocks higher.
 

According to your source Bulldozer does hold its own. Nowhere in my statement did I call it best. I said it did as it was designed heavy multithreading it is the bulldozer's bread and butter. Price for performance makes no difference to the vast majority of the companies running these style chips. The AMD box at the time of that writing outperformed the Intel and K10h based boxes. It doesn't matter if it had more ram, better hard drives or more cores. The point is the system was designed to do exactly that in a server environment and it succeeded in industry standard benchmarks. CEO's don't look at anandtech they look at the sheet of paper HP hands them that says quite clearly while at a higher cost performance per unit is higher. Less units at higher performance means less space.
 
Looking at this picture

bulldozer-overlay.jpg


BD doesnt look like a smart design. Really, why would you have L3 cache the same size as L2? L3 is slower than L2... but if it is the same size... what benefit does it add? Only prefetching algorithms aka "netburst"ing opcode and data. It isnt acting as a cache, but as a prefetcher. In which case, it doesnt need to be 2GB... it might at well just be 64K.

Redesign BD right away! A quick win would be to take L3 down to 64K... saving die space and power and making fab cost and end price much cheaper. I bet performance would be within 3% mark. Double L1 if not quadruple and performance would be up 10% and still on lower die footprint and power consumption.

And get the processor to operate symmetrically rather than asymmetrically. All this nonsense about affinity locking 2 threads and getting a "turbo boost" effect. Kill it. Separate those cores with a little space saved from cutting L3. And kill turbo boost but raise all clocks to their max. Cooling will be better now they are spaced and there isnt heat from L3.
 
Looking at this picture

http://img.techpowerup.org/111220/bulldozer-overlay.jpg

BD doesnt look like a smart design. Really, why would you have L3 cache the same size as L2? L3 is slower than L2... but if it is the same size... what benefit does it add? Only prefetching algorithms aka "netburst"ing opcode and data. It isnt acting as a cache, but as a prefetcher. In which case, it doesnt need to be 2GB... it might at well just be 64K.

Redesign BD right away! A quick win would be to take L3 down to 64K... saving die space and power and making fab cost and end price much cheaper. I bet performance would be within 3% mark. Double L1 if not quadruple and performance would be up 10% and still on lower die footprint and power consumption.

And get the processor to operate symmetrically rather than asymmetrically. All this nonsense about affinity locking 2 threads and getting a "turbo boost" effect. Kill it. Separate those cores with a little space saved from cutting L3. And kill turbo boost but raise all clocks to their max. Cooling will be better now they are spaced and there isnt heat from L3.

Each module can only use its 2MB L2 cache however the module could use the entire 8MB L3 if it needed.


As for the argument early the bulldozer die when analyzed the way AMD designed it has 4 ALU and 4 AGU per module. You would consider each module as a core. You cannot consider individual "cores" within the modules cores since they share the early pipelines. They are called integer cores. Each integer core carries a 4 way 16kB L1 data cache and a 64kB instruction cache. In a nutshell its two halves to a single brain, independent and codependent at the same time.
 
I wonder what the latency is between the different banks of L3. With decent memory controllers and DDR3, the relative performance gain of L3 cache is getting lower and lower... perhaps time to drop L3 and beef up L1/L2 and separate those pipelines.
 
I count 4 modules (cores)

Those are 8 cores just looking at that you wouldn't notice the repeated alu/agu subsets and the dedicated datapaths each one have

abinstein said:
You CLAIM a core is <whatever you claimed> but unfortunately what you claimed is not true.

What has always been the meaning of a "core" is the circuit used for the management of a thread and its memory context. This usually includes the datapath, control, and bus. This usually excludes the caches and accelerators (incl. FPU).

To be more precise, a processor can be partitioned into the following functional units: data cache, instruction data, { control unit, instruction bus, data bus, (integer) datapath } and (floating point) accelerator datapath. Those inside the {} above form a "core". You may ask: why is integer datapath special? Because any process (thread + memory context) is *always* managed by the integer datapath. Any branch instruction, ILP, OOO, speculation, is performed by the integer datapath.

So the question to ask is how many sets of the {} above does a Bulldozer module have? The answer is 2. There are two cores. This has nothing to do with marketing. It's a technical definition.

Now, you don't need to like this definition. You can be bone headed enough to insist on your own definition of core. That is fine. Just like you can insist 1+1=1. Perhaps you are right in an alternative naming convention (if `+' means the logic-or to you), but you should at least understand that a Bulldozer module is said to have "two cores" for very with sound technical reasons.

The threads don't compete all hyperthreading does is allow another set of instructions to be sent down the pipeline. It was originally a band-aid for Intel's long pipelined netburst based chips. AMD's new design gave you 2 separate threads something Hyperthreading can never do.

Hyperthreading competes for the execution resources....

Each module can only use its 2MB L2 cache however the module could use the entire 8MB L3 if it needed.

The 8MB of L3 is used mostly for big prefetches and it used by all modules and by all cores

As for the argument early the bulldozer die when analyzed the way AMD designed it has 4 ALU and 4 AGU per module. You would consider each module as a core. You cannot consider individual "cores" within the modules cores since they share the early pipelines. They are called integer cores. Each integer core carries a 4 way 16kB L1 data cache and a 64kB instruction cache. In a nutshell its two halves to a single brain, independent and codependent at the same time.

No the design was that the 2 AGLUs were able to execute non-memory workloads(With the later versions being able to having all EX/AGLUs be AGLUs that can be able to output 4 Adds, 4 Subtracts, 4 Multiply, 4 Divide, 4 Memory ops per cycle in any order as long as it outputted four and this is per core)....Each module has two cores. You can consider the individual cores in the module cores since they have dedicated datapaths, instruction buses, data buses, and control units...

Don't impose your definition of what a core is if you are 100% wrong!
 
Last edited:
Simply mind blowing how a single cjop can cause such a fusd
 
Those are 8 cores just looking at that you wouldn't notice the repeated alu/agu subsets and the dedicated datapaths each one have

They don't have entirely seperate datapaths. The initial pipelines are shared between the integer cores.




Hyperthreading competes for the execution resources....

These share the instruction set per module not core, and share all of the other resources.


The 8MB of L3 is used mostly for big prefetches and it used by all modules and by all cores

Which is what was already said.


No the design was that the 2 AGLUs were able to execute non-memory workloads(With the later versions being able to having all EX/AGLUs be AGLUs that can be able to output 4 Adds, 4 Subtracts, 4 Multiply, 4 Divide, 4 Memory ops per cycle in any order as long as it outputted four and this is per core)....Each module has two cores. You can consider the individual cores in the module cores since they have dedicated datapaths, instruction buses, data buses, and control units...

So each module acts as one core? giving 4 ALU/4 AGU per cycle. Thats exactly what I just said. Each module has dedicated datapaths, instruction buses, data buses and control units.

AMD_Bulldozer_block_diagram_%288_core_CPU%29.PNG


All shared within the module not within the integer core. The integer cores are not independant of the modules if they were it would be a true 8 core unit. No different than a Phenom X8 of sorts. This is not that. The integer cores share everything except a 16kB L1.

Don't impose your definition of what a core is if you are 100% wrong!

There are two definitions of a core and bulldozer fis neither.
 
Last edited by a moderator:
So each module acts as one core? giving 4 ALU/4 AGU per cycle. Thats exactly what I just said. Each module has dedicated datapaths, instruction buses, data buses and control units.


Each core has 2 EXALUs and 2 AGLUs the original specification is that there was going to be 4 AGLUs but that was a rumour made by Dresdenboy

Again each core has dedicated datapaths, instruction buses, data buses, and control units..

2 DATAPATHS, 2 IBUSES, 2DBUSES, 2ConUNITS => 2 CORES NOTHING IS SHARED

IT IS EIGHT CORES!

TECHNICAL DEFINITIONS PLACE BULLDOZER of the OROCHI DIE AT EIGHT CORES

amd_bulldozer_core_module_zoom.jpg


abinstein said:
You CLAIM a core is <whatever you claimed> but unfortunately what you claimed is not true.

What has always been the meaning of a "core" is the circuit used for the management of a thread and its memory context. This usually includes the datapath, control, and bus. This usually excludes the caches and accelerators (incl. FPU).

To be more precise, a processor can be partitioned into the following functional units: data cache, instruction data, { control unit, instruction bus, data bus, (integer) datapath } and (floating point) accelerator datapath. Those inside the {} above form a "core". You may ask: why is integer datapath special? Because any process (thread + memory context) is *always* managed by the integer datapath. Any branch instruction, ILP, OOO, speculation, is performed by the integer datapath.

So the question to ask is how many sets of the {} above does a Bulldozer module have? The answer is 2. There are two cores. This has nothing to do with marketing. It's a technical definition.

Now, you don't need to like this definition. You can be bone headed enough to insist on your own definition of core. That is fine. Just like you can insist 1+1=1. Perhaps you are right in an alternative naming convention (if `+' means the logic-or to you), but you should at least understand that a Bulldozer module is said to have "two cores" for very with sound technical reasons.

There are TWO Integer DATAPATHS, 2 CONTROL UNITS, 2 INSTRUCTION BUSES, 2 DATA BUSES GET IT IN YOUR GODDAMN BONEHEAD OF YOURS THAT THIS IS TWO CORES

Accept the facts and move on cdawall I am tired of your idiocy
 
Last edited:
*Reads through this thread and shakes head*

You guys are relentless on debating...

nothing-to-do-here-template.jpg
 
Each core has 2 EXALUs and 2 AGLUs the original specification is that there was going to be 4 AGLUs but that was a rumour made by Dresdenboy

Again each core has dedicated datapaths, instruction buses, data buses, and control units..

2 DATAPATHS, 2 IBUSES, 2DBUSES, 2ConUNITS => 2 CORES NOTHING IS SHARED

IT IS EIGHT CORES!

TECHNICAL DEFINITIONS PLACE BULLDOZER of the OROCHI DIE AT EIGHT CORES

Lets go through your image specifically. Having separate datapaths means nothing when there is still only a single unit. 2 roads to the same place if you will.

inst639.jpg


The module is not actually split into 2 cores that is the idea behind Bulldozer fit more into the package. In the image I split it for simplicity the only section physically separate for the cores is the actual integer calculation sections with their cache. Everything else is shared again separate paths to the same place don't make the place anymore split. The cores would still have to share. Any communications outside of the module go core->module->IO not core->IO once again making the dependent of the module itself further making them not into a true core as is normal for a K10 or SB style CPU. This is a new design with separate integer cores within modules. They are not the same cores as anything else to this point utilizes. While an 8150 has 8 integer cores it does not have 8 separate processing modules like a Phenom X8 would.
 
I've been making that argument since before it launched and nobody seemed to care. Thank you for perfectly detailing what I couldn't.
 
I've been making that argument since before it launched and nobody seemed to care. Thank you for perfectly detailing what I couldn't.

It took me about 3 hours of reading a looking at different architectural designs to figure out how to finally phrase it. :laugh: Thanks AMD for making shit more difficult again :slap:
 
Um......like I said. Its not an 8 core.

BTW thanks for detailing it cdawall. Really. I honestly didn't have the time and you did a better job then I could have. (Internet high five!) Bulldozer is only a fail to people who rested all of thier childhood expectations on a piece of silicon to enhance their mortality OR Intel fanboys who have small manhood's. Anyone with a brain can see what its design is for. Sometimes you don't get what you want, you get what you need.
 
I think you're deluding yourself by expecting 10% on average. I saw some Linux Benchmarks and W8 Benchmarks with a "fixed" scheduler, and it was MAYBE a 5% gain in some situations, and in other upowards of a 5% loss in performance. This patch may offer a slight performance gain, but I don't expect it to really change much.
Think about this, you have a scheduling issue, something that obviously needs to get fixed. I don't think 10% on average is unreasonable.
The same can be said in a busy doctor's office or in a hospital, if you don't schedule appointments properly, you end up running into patient bottlenecks.
We will know the facts soon enough in Q1 2012, and hopefully this 2 part patch will help efficiency within the Bulldozer and make it close to the way it was meant to run and perform.
 
Back
Top