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 435495
To read all comments associated with this story, please click here.
Switch to another thread when busy?
by Kebabbert on Thu 5th Aug 2010 11:26 UTC
Kebabbert
Member since:
2007-07-27

Sun SPARC Niagara can switch to another thread in one clock cycle, so in effect Niagara does not idle when waiting for data from RAM. It works with another thread.

When common cpus switches thread it takes 100s of clock cycles. That is one of the reasons a normal x86 server waits for data from RAM, 50% of the time - under full load. Under max load, an x86 idles 50% of the time, waiting for data from RAM. According to studies from Intel.

So, a Niagara at 1.4GHz (with 64 threads) can easily beat a POWER6 at 5GHz on multithreaded workloads. Because Niagara does not idle, it just works with another thread.

Todays CPUs are very fast, but RAM is slow. If you have 10GHz cpu, then it will wait 90% of the time for data from RAM. The higher clocked cpus, the more it waits when the pipeline stalls.

Reply Score: 5

ndrw Member since:
2009-06-30

There is no such thing as "one cycle" anymore. If you wanted to switch context instantaneously, you'd have to implement something equivalent to HT. And what HT does is not really a context switch - it's a hardware level emulation of two CPU's. From the system perspective, it looks like two CPU's concurrently executing two threads. Except that it is really a single core, executing a single thread, and maybe another thread will have a chance to proceed if the first one happens not to be optimized enough. True in case of "regular" processes, very likely false in case of codecs, numerical procedures etc.

This mechanism interferes with the system scheduler by pretending to do something else than it really does. In certain scenarios (high load with number crunching apps) this may compromise stability of the whole system.

Reply Parent Score: 1