FordGT90ConceptSeagate got sued and lost because Seagate's definition of "GB" (10^9) varied from Microsoft's definition of "GB" (2^30).

All windows application up to windows 10 have labeled it per core not per module/thread.

Modules are purely a hardware construct. It is invisible to software.

Windows 8.1 and newer see "sockets," "cores," and "logical processors." Is Windows wrong?

VulkanBros

That's why I asked. Linux may be in agreement with Windows that FX-6350 is a tri-core.

FordGT90ConceptModules are purely a hardware construct. It is invisible to software.

Windows 8.1 and newer see "sockets," "cores," and "logical processors." Is Windows wrong?


That's why I asked. Linux may be in agreement with Windows that FX-6350 is a tri-core.

Knoppix lists the 8320 and 4350 as 8 and 4 core units. They are physically there, so how are they only logical cores?

and I apoligize windows 8.1 and 10 are the only ones that list them as logical, which is merely a function of the task scheduler.

I think you're wasting your breath. I remember back when this thread was started he was talking about the iGPU found on the FX chips.

News to me :laugh:

It's a frivolous lawsuit.

The GTX970 comparison isn't comparable; nvidia outright lied about things such as ROP/TMU count. The 3.5 + 0.5 memory is up in the air.

AMD sold you 8 cores, and you got 8 cores you can assign work to. When I encode 8 music tracks at once on my "4 core" FX-8320, I get double the encoding performance as I do encoding 4 tracks at once. Shocker.

cdawallKnoppix lists the 8320 and 4350 as 8 and 4 core units. They are physically there, so how are they only logical cores?

How many cores do you see?

I count four. Top left, top right, bottom left, bottom right.

Here's an actual 8-core Xeon 7500 series:

Doesn't matter? It has 8 calculation units that can work independently until the need the FPU.

FordGT90ConceptWindows 8.1 and newer see "sockets," "cores," and "logical processors." Is Windows wrong?

Windows can't even agree with itself. A lot of the bulldozer APUs get listed as 4c/4t in TaskManager.

FordGT90ConceptThey aren't physically there. Die shot of Opteron 6386 SE. Where are the 16 cores? I can only see eight.

Probably because that die only has 8 cores. The 6386, and all 16-core 6300 series opterons are two of those dies side by side.

Like this:


You can read more about where this die shot comes from here: www.theregister.co.uk/2012/11/05/amd_opteron_6300_server_chip/

So, yeah, that die you say you can see 8 cores in. It is an 8-core bulldozer die, not a 16. So you just admitted that it is 8-Cores, not 4. Ooooooops.

I edited because I realized the mistake (the picture actually comes from earlier in this thread). Here's the two side by side, equivalent hardware circled:


I see 8 in your picture, not 16.

As to my mistake, I do see 8 components, two in each white box but there's no clear line separating them; hence, I see four cores.

Here's the post: www.techpowerup.com/forums/threads/amd-dragged-to-court-over-core-count-on-bulldozer.217327/page-3#post-3367260

Wait I have one how many cores does this have?

I'm thinking quad-core (center to the right, L2 above them). Most of that die is GPU. How many GPU cores? I'm not going to guess because it's such a mess.

FordGT90ConceptHere's the two side by side, equivalent hardware circled:

Actually, did you notice how in the areas you circled, there are an almost identical mirror of hardware in certain places? You can not tell me you didn't notice these two isanely identical areas inside the areas you circled.

FordGT90ConceptWhy does it say "cpu cores : 3"


Seagate got sued and lost because Seagate's definition of "GB" (10^9) varied from Microsoft's definition of "GB" (2^30).

No modules are seen by the kernel, in fact, it's why Windows needed a patch also. If you knew anything about computer engineering and how addresses works, you would understand. It's the same thing for Atoms modules, they are seen at first as one virtual core containing two physical cores, or for Intel it can be 2 threads. The addressing is working like that, to send an instruction you need the address of the processor, which is the physical ID, then the module is seen as a core, and the core is seen a thread. That's how they adapted modules in Linux and Windows, by adapting the threading to the modules. It's getting technical from there, and you would have to know how a processor actually work, and how modules work. Like i said, the Intel Atoms have the same exact way to address the cores, by using the modules to dispatch to the cores, just like if it were threads. Just communicate with a Windows programmer and he will tell you there is no "agreement" of Windows seeing the module as a core. For addresses, it function the exact same way as threading. There's 4 addresses passed to direct the instructions to the core/thread you want. The format is Addr1->Addr2->Addr3. First is the logical processor, which is the socket, then there's the virtual processor, which can be a module or the core, then you have the physical processor, which can be a physical thread or a core. It's also why a core in a module, it can be AMD, Intel, SPARC, ARM, MIPS, it can't have a module with cores with hardware threads, because we would have to rethink the addressing entirely to include the 4th address, hence why Intel processors with cores in modules, don't have hyperthreading. That's how they made modules work, because the kernel don't make a distinction between a core or a thread, and is dispatching the load to the first address, with the second address and the third address. And yes, the kernel is software, and it's the thing controlling the hardware. Instead of ending up in a hardware thread, the instruction end up in a hardware core, the logical core (hyperthreading) is dispatching threads the EXACT same way a module is dispatching to the cores, but instead of ending up in a hardware thread, it ends up in a physical core.

So YES, modules are totally a hardware construct for the kernel, but so are also the cores. But no they are not invisible for the kernel, it's just the same thing for it, address1/2/3, that's it. The kernel is not asking the processor : "Hey, are you a core or a module?".

You remind me of the retards when hyperthreading got out, saying : "look, look, i have 8 processors", and we responded by : "no it's not processors, it's cores, and 4 of them go to the same core, but Windows see them as cores". And arguing eternally because they don't know anything of what they are talking about.

It's what we are trying to explain to you, it's working the EXACT same way as hyperthreading, but at the end, instead of having 8 "logical cores", alternating between two entries on the same physical core, it's going to a real physical core. Instead of using one thread to fill holes in the physical core by dispatching two threads in same time, it is a module dispatching two threads between two physical cores in same time in the module. It behave like hyperthreading, but it is not hyperthreading.

If you want it explained by someone being in engineering :

newtekie1Actually, did you notice how in the areas you circled, there are an almost identical mirror of hardware in certain places? You can not tell me you didn't notice these two isanely identical areas inside the areas you circled.

It's not that cut and dried. Here's major parts I found that were mirrored. As I said before, Siamese twins.

Edit: And now I see another problem. The line on the second from the top big box needs to be shifted to the left a little bit.

MalakiLabNo modules are seen by the kernel, in fact, it's why Windows needed a patch also. If you knew anything about computer engineering and how addresses works, you would understand. It's the same thing for Atoms modules, they are seen at first as one virtual core containing two physical cores, or for Intel it can be 2 threads. The addressing is working like that, to send an instruction you need the address of the processor, which is the physical ID, then the module is seen as a core, and the core is seen a thread. That's how they adapted modules in Linux and Windows, by adapting the threading to the modules. It's getting technical from there, and you would have to know how a processor actually work, and how modules work. Like i said, the Intel Atoms have the same exact way to address the cores, by using the modules to dispatch to the cores, just like if it were threads. Just communicate with a Windows programmer and he will tell you there is no "agreement" of Windows seeing the module as a core. For addresses, it function the exact same way as threading. There's 4 addresses passed to direct the instructions to the core/thread you want. The format is Addr1->Addr2->Addr3. First is the logical processor, which is the socket, then there's the virtual processor, which can be a module or the core, then you have the physical processor, which can be a physical thread or a core. It's also why a core in a module, it can be AMD, Intel, SPARC, ARM, MIPS, it can't have a module with cores with hardware threads, because we would have to rethink the addressing entirely to include the 4th address, hence why Intel processors with cores in modules, don't have hyperthreading. That's how they made modules work, because the kernel don't make a distinction between a core or a thread, and is dispatching the load to the first address, with the second address and the third address. And yes, the kernel is software, and it's the thing controlling the hardware. Instead of ending up in a hardware thread, the instruction end up in a hardware core, the logical core (hyperthreading) is dispatching threads the EXACT same way a module is dispatching to the cores, but instead of ending up in a hardware thread, it ends up in a physical core.

So YES, modules are totally a hardware construct for the kernel, but so are also the cores. But no they are not invisible for the kernel, it's just the same thing for it, address1/2/3, that's it. The kernel is not asking the processor : "Hey, are you a core or a module?".

Got links for that?

MalakiLabIt's what we are trying to explain to you, it's working the EXACT same way as hyperthreading, but at the end, instead of having 8 "logical cores", alternating between two entries on the same physical core, it's going to a real physical core "integer cluster." Instead of using one thread to fill holes in the physical core by dispatching two threads in same time, it is a module dispatching two threads between two physical cores "integer clusters" in same time in the module. It behave like hyperthreading, but it is not hyperthreading.

FTFY

I called it "hybridized simultaneous multithreading." It's not Hyper-Threading Technology but it also isn't a dual core. It's something in between. At bare minimum, they should have called it "8-core*" with fine print saying it has 8 integer clusters and explaining what that means in laymen terms.

MalakiLabIf you want it explained by someone being in engineering :

Nothing new in there.

Yet, somehow we completely ignore the part where integer ALUs are a fundamental building block of any microprocessor whereas the FPU has always been an add-on.

Tell me, by that definition does the Intel 8080 or 8088 not contain a CPU core because it lacks a FPU?

FordGT90ConceptIt's not that cut and dried. Here's major parts I found that were mirrored. As I said before, Siamese twins.

Edit: And now I see another problem. The line on the second from the top big box needs to be shifted to the left a little bit.


Got links for that?


FTFY

I called it "hybridized simultaneous multithreading." It's not Hyper-Threading Technology but it also isn't a dual core. It's something in between. At bare minimum, they should have called it "8-core*" with fine print saying it has 8 integer clusters and explaining what that means in laymen terms.


Nothing new in there.

What you do for a living? I am a software engineer. My speciality is multicore, multiprocessor. Don't try to correct me, it is two physical cores. If you don't compile with extreme vectorization, a module behave like 2 cores. It's 2 physical cores, with assigned it's own designated FMAC and 128-bit Integer. You can't pretend like you know anything about instructions and how a processor behave, you have no idea. The pictures you are posting are ridiculous, it's normal for a die not to be perfectly symmetric.

You come here and you pretend you know more than people who studied way more than you did. That's what i do for a living, i study how programs compile on multicore processors, how the cores are behaving, how the threads are behaving, how the kernel handling the the threads, how GCC is handling the threads, then how the compiled program handle the threads. Then i optimize the sources of the package and usually make recommendations to the kernel and GCC dev teams on how the CFLAGS are behaving on precise architecture and microarchitecture.

I can tell that,
CFLAGS="-march=bdver2 -mmmx -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -maes -mpclmul -mpopcnt -mabm -mlwp -mfma -mfma4 -mxop -mbmi -mtbm -mavx -msse4.2 -msse4.1 -mlzcnt -mf16c -mprfchw -mfxsr -mxsave --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver2 -fstack-protector-strong -O2 -pipe"
will do a good job at handling all cores and producing quality binaries.

But in fact,
CFLAGS="-march=bdver2 -mmmx -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -maes -mpclmul -mpopcnt -mabm -mlwp -mfma -mfma4 -mxop -mbmi -mtbm -mavx -msse4.2 -msse4.1 -mlzcnt -mf16c -mprfchw -mfxsr -mxsave --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver2 -fstack-protector-strong -O3 -pipe" is too much vectorization for the -mavx, and the FP Scheduler can't follow and the FPU becomes a burden too heavy for the advantage of CPU cycles you get by using it to vectorize instead of of SSE. I am programming in assembly, i invoke the instructions myself and see how the processor behave if i begin threading it to the max, what is the breaking point.

You don't even know how the scheduler works. Even AMD engineers took so much time understanding how to handle such a complex task. They went even nearer with the Excavator architecture, but it would take too much time to get it to perfection, meanwhile Intel is improving it's IPC to the max, and the they can't compete. People want more power.

What they learnt with the Bulldozer is not wasted. Because they are introducing some ARM co-processor in their processor, which will have to be shared.

Just go check en.wikipedia.org/wiki/ARM_big.LITTLE

The big.LITTLE architecture is recognized as Octocore. Even if the Cortex-A7 is shared with an A15 in a virtual core module, and in that configuration, they share the same VFPv4 Floating Point Unit, and the Cortex-A7 is mainly just used for low power THUMB-2 instructions. It is not uncommon practice, and no engineer ever will tell you those two cores inside the module are just one. Not a single one.



If you are interested in seeing a real operating system taking full advantage of the AMD cores, i began doing some videos of distributed compilation, on which i study afterwards the details of how the processor performed. 25 years of experience in engineering.


For me the debate finish here. If you are really interested in knowing how much you are wrong, go study x86 instruction set and more precisely x87 subset and how they are implemented in modern processors. When you will be ready in a few years, we will have the same conversation.

AquinusYet, somehow we completely ignore the part where integer ALUs are a fundimental building block of any microprocessor whereas the FPU has always been an add-on.

Tell me, by that definition does the Intel 8080 or 8088 not contain a CPU core because it lacks a FPU?

"Cores" didn't exist in 1980s. You're taking a word defined circa 2006 and retroactively applying it. When the word was defined, it effectively meant two processors and that's what it stayed through today.

FordGT90Concept"Cores" didn't exist in 1980s. You're taking a word defined circa 2006 and retroactively applying it. When the word was defined, it effectively meant two processors and that's what it stayed through today.

The word still has no definition.

FordGT90Concept"Cores" didn't exist in 1980s. You're taking a word defined circa 2006 and retroactively applying it. When the word was defined, it effectively meant two processors and that's what it stayed through today.

It was the most simple definition of a compute core. They didn't have multi-core CPUs but, that was a CPU with a single core capable of serial computation. Even modern day microcontrollers sometimes lack a FPU because it may not be necessary for the task. CPUs complex enough where they need to execute more than one instruction in parallel are bound to have a FPU because it's already complex enough to be a general processor, not merely a micro-controller but, that doesn't change anything. The simple fact is that a computer does not need an FPU to operate but, it needs ALUs. Sure, it's harder to solve certain problems without a FPU but such difficulties doesn't make it not a core.

The 8088 was also small enough where a system could be wired out to support more than one 8080 on the same system. Software merely didn't support it.

MalakiLabWhat you do for a living? I am a software engineer. My speciality is multicore, multiprocessor. Don't try to correct me, it is two physical cores. If you don't compile with extreme vectorization, a module behave like 2 cores. It's 2 physical cores, with assigned it's own designated FMAC and 128-bit Integer. You can't pretend like you know anything about instructions and how a processor behave, you have no idea. The pictures you are posting are ridiculous, it's normal for a die not to be perfectly symmetric.

You come here and you pretend you know more than people who studied way more than you did. That's what i do for a living, i study how programs compile on multicore processors, how the cores are behaving, how the threads are behaving, how the kernel handling the the threads, how GCC is handling the threads, then how the compiled program handle the threads. Then i optimize the sources of the package and usually make recommendations to the kernel and GCC dev teams on how the CFLAGS are behaving on precise architecture and microarchitecture.

I can tell that,
CFLAGS="-march=bdver2 -mmmx -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -maes -mpclmul -mpopcnt -mabm -mlwp -mfma -mfma4 -mxop -mbmi -mtbm -mavx -msse4.2 -msse4.1 -mlzcnt -mf16c -mprfchw -mfxsr -mxsave --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver2 -fstack-protector-strong -O2 -pipe"
will do a good job at handling all cores and producing quality binaries.

But in fact,
CFLAGS="-march=bdver2 -mmmx -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -maes -mpclmul -mpopcnt -mabm -mlwp -mfma -mfma4 -mxop -mbmi -mtbm -mavx -msse4.2 -msse4.1 -mlzcnt -mf16c -mprfchw -mfxsr -mxsave --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver2 -fstack-protector-strong -O3 -pipe" is too much vectorization for the -mavx, and the FP Scheduler can't follow and the FPU becomes a burden too heavy for the advantage of CPU cycles you get by using it to vectorize instead of of SSE. I am programming in assembly, i invoke the instructions myself and see how the processor behave if i begin threading it to the max, what is the breaking point.

You don't even know how the scheduler works. Even AMD engineers took so much time understanding how to handle such a complex task. They went even nearer with the Excavator architecture, but it would take too much time to get it to perfection, meanwhile Intel is improving it's IPC to the max, and the they can't compete. People want more power.

Nice lack of links.

MalakiLabWhat they learnt with the Bulldozer is not wasted. Because they are introducing some ARM co-processor in their processor, which will have to be shared.

Just go check en.wikipedia.org/wiki/ARM_big.LITTLE

The big.LITTLE architecture is recognized as Octocore. Even if the Cortex-A7 is shared with an A15 in a virtual core module, and in that configuration, they share the same VFPv4 Floating Point Unit, and the Cortex-A7 is mainly just used for low power THUMB-2 instructions. It is not uncommon practice, and no engineer ever will tell you those two cores inside the module are just one. Not a single one.

I'm not finding any big.LITTLE chip that separated the FPU from its respective cores. If what you say is true about the FPU sharing, that's effectively turning one of the cores into a co-processor. That doesn't change the fact it has 8 distinct cores that are capable of functioning independently of each other.

Edit: Also, die shot:

I see 8 distinct processors.

cdawallThe word still has no definition.

If this goes to court, it will be legally defined.

AquinusIt was the most simple definition of a compute core. They didn't have multi-core CPUs but, that was a CPU with a single core capable of serial computation. Even modern day microcontrollers sometimes lack a FPU because it may not be necessary for the task. CPUs complex enough where they need to execute more than one instruction in parallel are bound to have a FPU because it's already complex enough to be a general processor, not merely a micro-controller but, that doesn't change anything. The simple fact is that a computer does not need an FPU to operate but, it needs ALUs. Sure, it's harder to solve certain problems without a FPU but such difficulties doesn't make it not a core.

The 8088 was also small enough where a system could be wired out to support more than one 8080 on the same system. Software merely didn't support it.

Been over all that already. FPUs have been intrinsic to x86 design since the mid 1990s. A core has been established as a complete processor (as in take an uniprocessor, take away the memory controller, slap it on a die with another uniprocessor, add back in the memory controller, and a bus to communicate with the rest of the system) since circa 2006. You're using excuses from lifetimes ago in technology to justify what AMD did. AMD should know better that if you're going to redefine things, you better make it damn clear on the box. AMD is going to lose this and they're going to lose hard. The case against AMD is stronger than the case against Seagate which Seagate lost.

FordGT90ConceptIf this goes to court, it will be legally defined.

Good on them, because up until this point there isn't nor has there ever been a definition of a core.

FordGT90ConceptNice lack of links.

What they learnt with the Bulldozer is not wasted. Because they are introducing some ARM co-processor in their processor, which will have to be shared.

Just go check en.wikipedia.org/wiki/ARM_big.LITTLE


I'm not finding any big.LITTLE chip that separated the FPU from its respective cores. If what you say is true about the FPU sharing, that's effectively turning one of the cores into a co-processor. That doesn't change the fact it has 8 distinct cores that are capable of functioning independently of each other.


If this goes to court, it will be legally defined.


Been over all that already. FPUs have been intrinsic to x86 design since the mid 1990s. A core has been established as a complete processor (as in take an uniprocessor, take away the memory controller, slap it on a die with another uniprocessor, add back in the memory controller, and a bus to communicate with the rest of the system) since circa 2006. You're using excuses from lifetimes ago in technology to justify what AMD did. AMD should know better that if you're going to redefine things, you better make it damn clear on the box. AMD is going to lose this and they're going to lose hard. The case against AMD is stronger than the case against Seagate which Seagate lost.

The Cell Broadband you will CLEARLY find it. 1 PPE core, 8 SPE cores.

en.wikibooks.org/wiki/Microprocessor_Design/Multi-Core_Systems

You can't tell me IBM is wrong. The PPE don't have any FPU, it transfers them to the external SPEs, who just do Floating-Point calculations external to the PPE. Yet the PPE and the SPEs are called cores. Because that's what they are, cores. Even if you can't do nothing alone with an SPE, it's still called a core, seen as cores, behave like cores. The processor is considered as 9 cores.

You can't even dare say you know better than IBM what constitute or don't constitute a core.

Or you can take Nvidia too. They claim they have 2560 Cuda cores in their GTX 1080. When ALL they have in a core is an FPU, and there's 50 Cores in a module, with only a scheduler, a dispatcher, and all it can do is floating-point operations in parallel.





No one, no company can define with precision what consist of a core. If AMD decide it's 2 Piledriver cores fused together with one shared FPU, it is. Even if they had no FPU at all. It is still 2 cores in one module.

PPE supports VMX (page 20), aka AltiVec, which is cable of single-precision floats. A primitive FPU but an FPU none the less. Only the PPE fits the definition of a "core." SPEs could be considered co-processors in the sense that 8087 was a co-processor.

I'd argue GPUs don't have cores because they can't function without a CPU to give them orders. They are always incomplete. They're more like SPEs (co-processors) than PPEs (processors). That said, AMD, Intel, NVIDIA, ARM, etc. play fast and loose with what they call most of the components of their GPUs. One can't reasonably draw a box around a broad component and call that something universal. Case in point: compare the above to GCN:

Not much agreement on what to call anything. That said, NVIDIA choose to mimic GCN with Pascal to improve Pascal's virtual reality performance.

The nature of the thread has dictated CPU layout. GPU layout has changed drastically over the years.

FordGT90ConceptBeen over all that already. FPUs have been intrinsic to x86 design since the mid 1990s. A core has been established as a complete processor (as in take an uniprocessor, take away the memory controller, slap it on a die with another uniprocessor, add back in the memory controller, and a bus to communicate with the rest of the system) since circa 2006. You're using excuses from lifetimes ago in technology to justify what AMD did. AMD should know better that if you're going to redefine things, you better make it damn clear on the box. AMD is going to lose this and they're going to lose hard. The case against AMD is stronger than the case against Seagate which Seagate lost.

Last time I checked, x87 and other floating point instructions are still extensions to X86. Archaic or not, it doesn't change the fact that any machine using X86 can not operate without integer cores whereas it can be done without FPUs, it's just not done anymore because it doesn't make sense given general purpose workloads but, that doesn't change the fact about how the CPU works and what's required for it to be able to operate. x87 is still a co-processor, the only difference now is that it's on the same die as the integer ALUs and the rest of the CPU logic but, that doesn't mean that it's required to call it a compute core. I've used microcontrollers that have absolutely no ability to do floating point math, but they still have a compute core that can access memory, execute instructions, and do everything a CPU would do except floating point math.

So, you can make the same case until your blue in the face but, the simple fact is that X86 is nothing without integer cores and can operate without an FPU just fine, just because all general purposes CPUs now come with FPUs is beside the point. Do AMD and nVidia GPUs only have one core because they only have one UVD (or similar,) core for video playback? Every GPU nowadays has one, so why not? It's not mandatory for the operating of a GPU but most people get a lot of use out of video acceleration. The FPU is no different. It makes your life easier but, it is by no way required for the operation of X86. Whether it's connected by and external bus or on the same die, it's still a co-processor.

Simply put, there is no such thing as an x86 CPU capable of only doing floating point math while lacking integer ALUs and compute. That alone should tell anyone that the FPU is not a dictator for what should be considered a compute core. Once again x87, SSE, MMX, and all the other floating point math extensions are exactly that, extensions.

Aquinus...that doesn't mean that it's required to call it a compute core.

It's the industry standard and has been for decades.

AquinusI've used microcontrollers that have absolutely no ability to do floating point math, but they still have a compute core that can access memory, execute instructions, and do everything a CPU would do except floating point math.

We're talking about general processors here, not microcontrollers.


The only reason why x86 doesn't include the x87 standard is because they both go back to distinct processors decades ago. Most architectures designed after the creation of the IEEE754 standard have FPU features standard. One example of this is IA-64. The only reason x87 remains an extension is because of backwards compatibility. In practice, it is not separate. Every processor built on it in the last decade, almost two, have an FPU--even Bulldozer.


This is all very irrelevant anyway because a core is a core, not an integer cluster. AMD, at best, is going to settle which means they don't admit guilt to misleading the public. At worse, it will go to court, AMD will lose, and they'll likely have to pay out hundreds of millions or billions for making consumers think they got twice what they got.

FordGT90ConceptThis is all very irrelevant anyway because a core is a core, not an integer cluster. AMD, at best, is going to settle which means they don't admit guilt to misleading the public. At worse, it will go to court, AMD will lose, and they'll likely have to pay out hundreds of millions or billions for making consumers think they got twice what they got.

You keep saying AMD will loose. How? they are not incorrect there is not a standard for what a core is and the second core of the module sure as hell isn't a thread so does that mean AMD can countersue Microsoft for misleading the public on what a thread is? Where does this nonsense end. It can act independently, it can do all of the work a core can minus FPM which has never been a written requirement of a core.