Reply to post: Jeez it's tricky...

Jeez it's tricky...

Jeez this is a tricky one. (I'll call the module "2 cores" here to keep the sentences readable -- I'm not sure which side of the fence I'm on .) So, the AMD design has seperate integer and load/store units per Ccore, but shared almost everything else, and call them seperate cores.

A point toward them NOT being cores... hyperthreading. When this was added to the P4s, what happened was Intel added additional execution units to each core compared to older P4s, but found the scheduler was very frequently unable to keep a reasonable fraction of these execution units busy. So, they added the hyperthreading, where it would show an extra "CPU" that would only utilize execution units unused by the real CPU. They did not refer to a single-core with hyperthreading as a dual-core.

A point toward them being cores... with hyperthreading, it was possible for well-optimized code to keep all (or nearly all) execution units busy on the "real" CPU, so the hyperthreading CPU would make little or no forward progress. With this setup, each core *does* have some dedicated resources so neither will stall.

As for performance... again tricky. I mean, if they touted a certain per-core performance, and it regularly only gets 1.5x that performance on dual cores (instead of more or less 2x) that's not good. But, in this modern era, you've got CPUs allowing some cores to run faster if others aren't running, power gating, throttling to limit to a given TDP, and so on. Shared cache between cores is common; sharing branch prediction units is highly unusual but (perhaps) smart... most software is not branching constantly, so sharing a branch prediction unit between 2 cores shouldn't slow things down much. The shared FPU is odd; but it's possible they used a single faster FPU over giving each core a smaller, simpler, slower FPU, and although this means FPU performance can vary somewhat (depending on what is happening on the other core) that FPU performance ins overall better than it would be otherwise.

Really, for this "the devil is in the details".