Is there any reason that both of these cores need to be the same speed? Why not have one core that is 10% slower, and another core that is 40% slower? That way the overall performance would still be 1.5x, but programs already written and optimized for single core processors would not suffer as much.
cube
@ragnarok451 Clarification question: would the OS pick which core a certain job got sent to, and if so, how would it decide?
Kapteyn
@ragnarok451 Your suggested architecture might be better if you expect that most of the programs you run consist of one thread that has a high level of ILP to exploit and another that doesn't (I am assuming you could achieve such an architecture by perhaps removing more parts responsible for fancy superscalar tasks from one core than the other so that the core with more parts left in takes up more space on the chip but runs only 10% slower as opposed to 40% slower. Remember that we are only able to fit two cores on a chip because we are removing parts responsible for superscalar tasks).
However, if we assume that processes typically have approximately the same level of ILP to exploit (which is not an unreasonable assumption), it makes sense to remove the same amount of fancy superscalar architecture from both cores in order to be able to fit both on the chip.
fgomezfr
@ragnarok451 They probably don't need to be the same speed, but keeping in mind that voltage generally needs to increase with increasing clock speed, for similar workloads it's probably more power-efficient to keep them the same.
I believe most new CPU's (certainly my Intel processor) actually implement separate per-core clocks, and can even dynamically vary the clock rates to some extent. When one core is not being utilized at capacity, the voltage to the core can be reduced, even to the point of disabling the core. This is especially important for mobile CPU's - many smartphones now have quad-core processors, and since users don't do a lot of multitasking on such small screens, they can save battery life by shutting down unneeded cores.
plymouth
To add onto fgomezfr's point, in the Windows 8 Task Manager under the Performance tab you can see the current clock speed of your CPU. On my desktop it's pretty dynamic. I've had it go from 1.5 GHz to 3 GHz and back in the span of a few seconds just by opening a new chrome tab.
kayvonf
@fgomezfr: It's even more complex than that. Take for instance, the CPUs in the new Gates machines.
The base frequency is 2.2 GHz, but they can boost to 3.2 GHz. There's a lot of very sophisticated power management that goes on these days, and it goes far beyond just clocking down or shutting off cores to save power.
A modern way to think about things is that there's a total power budget for the chip, and the chip shifts the allocation of the power around to different components as appropriate. For example, if the chip is running one thread on one core, that core can boost to a higher frequency to deliver the best possible single-threaded performance. If all cores are running threads, the chip has to spread that power around, and so you'll likely observe lower per-thread performance since the cores can't clock as high. There's similar power-sharing going on between the CPU cores and the integrated on-chip GPU. For example, graphics performance can suffer if a game engine starts hitting the CPU hard because the CPU cores start sucking power away from the integrated GPU. My understanding is that CPU gets priority in current schemes.
kayvonf
Somewhat amusing side note: Dynamic power management is starting to make if very difficult for the course staff to deliver an assignment 1 experience where performance results are sufficiently consistent with "theory" that they are easy to understand for students attempting their first parallel programming assignment. :-( Effects of power management seem to be evident in the new Gates machines, which have 2014 Core i7's.
Student: "Wait, my program is running slower now than it was 30 seconds ago"
Staff: "That's because the CPU is hotter now than it was before, you ran your program a few times."
Is there any reason that both of these cores need to be the same speed? Why not have one core that is 10% slower, and another core that is 40% slower? That way the overall performance would still be 1.5x, but programs already written and optimized for single core processors would not suffer as much.
@ragnarok451 Clarification question: would the OS pick which core a certain job got sent to, and if so, how would it decide?
@ragnarok451 Your suggested architecture might be better if you expect that most of the programs you run consist of one thread that has a high level of ILP to exploit and another that doesn't (I am assuming you could achieve such an architecture by perhaps removing more parts responsible for fancy superscalar tasks from one core than the other so that the core with more parts left in takes up more space on the chip but runs only 10% slower as opposed to 40% slower. Remember that we are only able to fit two cores on a chip because we are removing parts responsible for superscalar tasks).
However, if we assume that processes typically have approximately the same level of ILP to exploit (which is not an unreasonable assumption), it makes sense to remove the same amount of fancy superscalar architecture from both cores in order to be able to fit both on the chip.
@ragnarok451 They probably don't need to be the same speed, but keeping in mind that voltage generally needs to increase with increasing clock speed, for similar workloads it's probably more power-efficient to keep them the same.
I believe most new CPU's (certainly my Intel processor) actually implement separate per-core clocks, and can even dynamically vary the clock rates to some extent. When one core is not being utilized at capacity, the voltage to the core can be reduced, even to the point of disabling the core. This is especially important for mobile CPU's - many smartphones now have quad-core processors, and since users don't do a lot of multitasking on such small screens, they can save battery life by shutting down unneeded cores.
To add onto fgomezfr's point, in the Windows 8 Task Manager under the Performance tab you can see the current clock speed of your CPU. On my desktop it's pretty dynamic. I've had it go from 1.5 GHz to 3 GHz and back in the span of a few seconds just by opening a new chrome tab.
@fgomezfr: It's even more complex than that. Take for instance, the CPUs in the new Gates machines.
http://ark.intel.com/products/80814/Intel-Core-i7-4785T-Processor-8M-Cache-up-to-3_20-GHz
The base frequency is 2.2 GHz, but they can boost to 3.2 GHz. There's a lot of very sophisticated power management that goes on these days, and it goes far beyond just clocking down or shutting off cores to save power.
A modern way to think about things is that there's a total power budget for the chip, and the chip shifts the allocation of the power around to different components as appropriate. For example, if the chip is running one thread on one core, that core can boost to a higher frequency to deliver the best possible single-threaded performance. If all cores are running threads, the chip has to spread that power around, and so you'll likely observe lower per-thread performance since the cores can't clock as high. There's similar power-sharing going on between the CPU cores and the integrated on-chip GPU. For example, graphics performance can suffer if a game engine starts hitting the CPU hard because the CPU cores start sucking power away from the integrated GPU. My understanding is that CPU gets priority in current schemes.
Somewhat amusing side note: Dynamic power management is starting to make if very difficult for the course staff to deliver an assignment 1 experience where performance results are sufficiently consistent with "theory" that they are easy to understand for students attempting their first parallel programming assignment. :-( Effects of power management seem to be evident in the new Gates machines, which have 2014 Core i7's.
Student: "Wait, my program is running slower now than it was 30 seconds ago"
Staff: "That's because the CPU is hotter now than it was before, you ran your program a few times."
Student: "Aaaaaaarrrrrrg."