Author: Tom Kerrigan
Date: 00:02:42 04/11/03
Go up one level in this thread
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
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.