Linked by David Adams on Wed 4th Aug 2010 18:28 UTC, submitted by estherschindler
Hardware, Embedded Systems Anyone contemplating a new computer purchase (for personal use or business) is confronted with new (and confusing) hardware choices. Intel and AMD have done their best to differentiate the x86 architecture as much as possible while retaining compatibility between the two CPUs, but the differences between the two are growing. One key differentiator is hyperthreading; Intel does it, AMD does not. This article explains what that really means, with particular attention to the way different server OSes take advantage (or don't). Plenty of meaty tech stuff.
Thread beginning with comment 435428
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Cores beat threads
by Zifre on Wed 4th Aug 2010 20:52 UTC in reply to "Cores beat threads"
Member since:

6 cores with 6 threads CPU will beat 4 cores with 8 threads CPU.

Unless if 4c/8t processor has much better design. If the performance per core is in same ballpark, cores win over logical threads.

True, but I think the point is that a 4 core CPU with 8 threads will beat a 4 core CPU with 4 threads. I think HT gives you both better performance per $ and per watt.

Reply Parent Score: 3

RE[2]: Cores beat threads
by iseyler on Wed 4th Aug 2010 21:13 in reply to "RE: Cores beat threads"
iseyler Member since:

Exactly. Hyper-Threading does give a performance boost if the application is designed to take advantage of it.

On an Atom-330 (Dual Core 1.6GHz), Hyper-Threading gives a 20% performance boost from our testing.

- Ian Seyler @ Return Infinity

Reply Parent Score: 1

RE[3]: Cores beat threads
by phoenix on Fri 6th Aug 2010 14:46 in reply to "RE[2]: Cores beat threads"
phoenix Member since:

The kicker comes when the OS scheduler doesn't differentiate between "logical CPU" and "physical CPU" and treats them both as "physical CPUs" with the same number of integer/fpu/execution units. Then it tries to schedule two threads that use the same physical resources, thus causing them to interfere with each other and actually slow things down.

FreeBSD had this issue in 5.x and 6.x. SCHED_BSD (the default scheduler) had no concept of "logical CPUs" and treated each HT "core" as a complete physical CPU. Enabling HT in the BIOS would actually slow things down when more than one app was running. The recommendation at the time was to disable HT in the BIOS and to run a non-SMP kernel (unless there were multiple physical CPUs in the system, of course).

SCHED_ULE in 7.x gained support for scheduling HT cores.

And SCHED_ULE in 8.x has gained more knowledge about NUMA, SMP, SMT, and all the other fun stuff, allowing it to better schedule threads according to what's actually available, where it's running, where the RAM is connected, etc.

Not sure about Linux scheduling, other than it went through the same process, but a lot quicker.

Similarly for Windows XP, which has (I believe) no concept of SMT, and treats an HT core as a full physical CPU. I believe Vista gained support for SMT scheduling, and 7 improved upon it. But don't know for sure.

Edited 2010-08-06 14:47 UTC

Reply Parent Score: 2