Author: Robert Hyatt
Date: 07:56:16 04/11/03
Go up one level in this thread
On April 11, 2003 at 03:02:42, Tom Kerrigan wrote: >On April 10, 2003 at 23:14:26, Robert Hyatt wrote: > >>On April 10, 2003 at 20:17:32, Tom Kerrigan wrote: >> >>>On April 10, 2003 at 11:12:24, Robert Hyatt wrote: >>> >>>>>My understanding of SMT is as follows. The processor divides its resources >>>>>(issue queue, functional units, cache, etc) among two threads. Now, I *think* >>>>>that said threads are equal, that is, that they both get 50% of the CPU. >>>>>Otherwise, special OS code would have to be written to support SMT. >>>> >>>>Correct so far, although in reality both threads get considerably less than 50% >>>>each >>>>as much of the time finds both threads waiting for something from memory or >>>>cache, >>>>or waiting on a result from a previous instruction. >>> >>>You could say the same thing about a single thread on a single processor, it's >>>not getting "100%" of the CPU's power because it's waiting for memory, cache, >>>previous instructions, blah blah blah. This is completely irrelevant. >>> >>>>But I don't buy the 50% stuff, the cpu is not that simple internally. One >>>>thread will run at >>>>nearly full speed and the other gets slipped into the gaps, which is what I see >>>>(at least) when >>>>running Crafty. And, when you get down to it, this is what should be expected >>>>because of >>>>how the threads get intermixed. A single thread almost _never_ runs at "full >>>>speed". In fact, >>>>most run well below 50% of max cpu speed, for obvious reasons. SMT simply moves >>>>that >>>>up a bit... >>> >>>We're talking about millions of "gaps" per second and equal numbers of gaps per >>>thread (because it's the same software doing basically the same thing), so sure, >>>on a nanosecond scale, the threads aren't getting 50% each, but on any >>>reasonable scale they are. >>> >>>-Tom >> >>It's not so clear. I can't find _anything_ that explains this particular >>detail. IE what happens if you have two micro-ops that you could issue right >>now, one for each thread, but there is only one "slot" open? I find no answer. >> >>But experience suggests that a thread gets favored there. IE the first YMP >>from Cray handled memory bank conflicts based on physical cpu number as the >>priority selector. Not a real good idea. What Intel did I can not find out, >>but it is likely that one "logical processor" gets favored over the other, for >>that reason. > >For _what_ reason? For the reason that the Cray YMP handled memory contention in >a certain way? For the reason that you can't find out how Intel resolves >scheduling contention? Sure Bob. > >Is it so hard to believe that the P4 might have a bit that gets toggled to >indicate which thread to execute instructions from? > >-Tom Yes it is hard to believe.
This page took 0 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.