Author: Matt Taylor
Date: 18:19:18 12/10/02
Go up one level in this thread
On December 10, 2002 at 21:13:28, Robert Hyatt wrote: >On December 10, 2002 at 20:33:34, Jeremiah Penery wrote: > >>On December 10, 2002 at 20:18:16, Robert Hyatt wrote: >> >>>On December 10, 2002 at 20:12:06, Jeremiah Penery wrote: >>> >>>>On December 10, 2002 at 20:00:11, Robert Hyatt wrote: >>>> >>>>>On December 10, 2002 at 16:43:29, Matt Taylor wrote: >>>>> >>>>>>They said that HT allows -concurrent- scheduling of threads, but the threads >>>>>>obviously cannot make use of the same execution resources. If this is correct, >>>>>>one thread would be spinning (consuming bandwidth to the L1 cache) while the >>>>>>other thread was doing real work. >>>>> >>>>>Again, think about what you just said, which is impossible to happen. If one >>>>>thread is smoking the L1/L2 cache, then it is not waiting for _anything_ and >>>>>once it is scheduled it will execute until the cpu decides to flip to the other >>>>>thread. Or until that thread does a pause. Whichever comes first. >>>> >>>>The point is that the spinning thread blocks no execution units. The processor >>>>can spin the idle thread all it wants, why should that stop it from scheduling >>>>the second thread, which _will_ use the execution units, to run at the same >>>>time? >>> >>> >>>I don't follow. The "spinning thread" completely fills the integer pipe... >> >>Processors have more than one integer pipe, and I'm sure that a spinning thread >>doesn't fill more than one. In a P4, which has dual-pumped ALUs, a spinning >>thread wouldn't even block a single pipe. That is, if the scheduler were smart >>enough to schedule other thread(s) to fill that unit. > >Somehow we are not on the same page. A single tight compute-bound loop can >_completely_ fill one pipe by itself with _no_ problems. The micro-ops >will simply stuff that pipe totally as every branch will be predicted >correctly... > >And if that thread is sucking up the cpu, the _other_ thread is going to >be hindered since it can probably use _everything_ in the CPU when it is >running... > > >> >>>The cpu doesn't execute two threads at a time, it flips and flops back and >>>forth between them. The spinning thread will _never_ give up control and has >>>to be either preempted by the cpu, or else it has to do a pause, as explained >>>in the intel white-paper on the subject... >>> >>>Otherwise the pause would _not_ be needed... >> >>What's the point of hyper-threading if two threads don't run at the same time? >>Yeah, sure, you can execute while one thread waits on memory or something, but >>it's certainly not the most efficient use. All the documentation I've seen >>suggests that if one thread is using, say, half the integer pipes, that another >>thread can be scheduled concurrently to use the other half of the pipes. > > > >What is the point in an operating system for executing two processes at the >same time? Because one blocks and the other uses those unused cycles. That >is the _only_ point of running more than one process at a time. That is the >only point for hyper-threading also. It has just moved a bit of the process >scheduling down into the CPU. The OS feeds the CPU two candidate processes >to "interleave" and the CPU does that at the hardware level, more efficiently. > >As far as sharing pipes, that can happen. But if one thread is burning one >pipe up doing useless work, that is lost cycles that the other thread can't >get to. Which is _the_ point for the "pause" instruction... The integer pipe feeds into 5 integer execution units which can be accessed concurrently each cycle. However, a spin-wait loop will only be able to use 1 unit because of register dependenies.
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.