Author: Robert Hyatt
Date: 20:14:26 04/10/03
Go up one level in this thread
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. Perhaps the details will come out over time. Or if I ever have time, I could force Linux to tie a unique process to a logical cpu and see if it is 50-50 or 70-30 or whatever... Not enough time at the present, however, but hyper-threading is new and it will take time for everything to be discovered.
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.