I would love for that to be how the theory works out in practice, seriously it would be a godsend in terms of time saved if I didn't have to waste all that time monkeying around with setting the thread affinity, but that just isn't how it works out for me.
If I don't lock the thread affinity here is what I get at 4.8GHz (clockspeed doesn't matter though, of course):
^ no affinity locking, task manager shows the 4 threads bouncing all over the cores, and peak GFlops is 132.4.
But when I affinity lock the threads to the logical cores here is what I get:
^ affinity locking delivers higher GFlops, 134.1 in this case.
Now I've only shown you 3 runs here but that is because it doesn't matter how many runs I do. Whether it is 3 or 10 or 25, locking thread affinity for me always results in higher GFlops at any clockspeed versus leaving the windows 7 scheduler to manage the threads. (I am using win7 x64 ult SP1 with all the latest updates)
And what about temperatures, well if we are getting less work done per second without affinity locking then we would expect there to be lower power consumption and lower core temperatures to come from that.
Here is an example of the peak core temperature (the hottest core as reported by coretemp) with and without affinity locking:
Notice how the peak core temperature is rock steady for the "affinity locked" case but jumps around quite a bit for the "no affinity" case. Also notice that the run with the affinity locked finishes sooner (temperature drops right after 1000s, before the temperature drops for the no affinity case).
Taking a look at the average temperature of all four cores over time depicts the same picture but we see the average temperature for the "no affinity locking" case is even more sporadic:
Note that in both cases the max temperature is the same, but the case with affinity locking sees a sustained level of peak temperature that the run without affinity locking experiences.
Likewise the Kill-a-watt readings, with affinity locking the kill-a-watt reads 238W for this setup. Without affinity locking the kill-a-watt readout will hit 238W very sporadically (once every 5minutes, maybe) but tends to run down around 233-235W - commensurate with the fact that it is doing less work per second so it uses less power per second.
And that is why I go to all the trouble and effort of affinity locking my LinX/IBT run on my hyperthreaded chips - if you want your hyperthread CPU to experience the most challenging thermal environment that LinX has to offer it then you will use 4 threads (not 8) and you will affinity lock those threads to logical (physical) cores and not leave it the scheduler to manage.
In theory the Win7 scheduler might be designed to need no intervention, but in practice, at least for me, it is leaving performance on the table that can be recovered by manually managing the core affinities.