| 1 |
Paul Hartman schrieb: |
| 2 |
> On Thu, Jun 11, 2009 at 3:07 PM, Kelly Hirai<kelly@×××××××.edu> wrote: |
| 3 |
>> the N270 is a single core with hyperthreading, which will apear as 2 |
| 4 |
>> cpus (with the same core id) in dmesg. |
| 5 |
> |
| 6 |
> Ah, I forgot about hyperthreading masquerading as multiple CPUs. In |
| 7 |
> that case, Maxim can safely disable SMP if he wants to. I don't know |
| 8 |
> if the theoretical speed gains of disabling SMP outweigh the |
| 9 |
> theoretical speed gains of enabling hyperthreading. I think it'll |
| 10 |
> probably be about the same either way. |
| 11 |
> |
| 12 |
|
| 13 |
Well, I don't know about real workloads but once I did a little |
| 14 |
benchmark: One versus two instances of `dd < /dev/zero | md5sum`. |
| 15 |
|
| 16 |
Two instances had a 30% higher throughput than one. I haven't tried it |
| 17 |
with disabled SMP but I really can't imagine that the extra scheduling |
| 18 |
would cost nearly enough to compensate for this. |
| 19 |
|
| 20 |
From a technical point of view, I think HT makes more sense for an Atom |
| 21 |
than for a Nehalem: The Atom has only one pipeline, no out-of-order |
| 22 |
execution and probably a less effective branch prediction. HT might |
| 23 |
compensate this. |
| 24 |
|
| 25 |
However, I'm wondering if it wouldn't have been better to implement |
| 26 |
out-of-order execution instead of HT (like VIA Nano, for example). Maybe |
| 27 |
HT doesn't need as many transistors as out-of-order execution? |
| 28 |
|
| 29 |
In the end, unless there is some hard evidence against the use of HT, |
| 30 |
I'd say: They've spend their transistor budget on HT, now we should use |
| 31 |
what we've got. |
Archives