I believe it's actually simultaneous, instructions from 2 different processes
can run in the same cycle against 2 different register files.
for some definition of 'simultaneous'. I suspect that netburst-HT simply
runs with a thread until it stalls, then switches. I don't think Intel
ever detailed which stalling events do this. in some of the initial papers
on netburst-HT, it was implied that the implementation was almost a
side-effect of how the chip tracks in-flight operations. since no modern
chip really has a unitary pipeline, HT might well tolerate one thread
chugging through a microcoded transcendental at the same time as another,
say, follows a pointer.
had assumed so but I appear to be confused about it. Hyperthreading keeps a
thread ready to take advantage of stalls in a preceeding thread, but
doesn't
ever actually perform a second instruction in one click tick, correct? One
I believe HT switching does happen cycle-by-cycle, and would guess that
in-flight ops from multiple threads can coexist (not executing on the same
unit in the same cycle, though.)
to me, this makes a lot more sense than manycore chips, actually.
manycore basically assumes that tracking inflight ops is the main scaling
problem with modern chips. that may be the case, but I've never really
heard it described as such.
imagine if, instead of 8 cores onchip, you just had 8 "thread sequence"
units that contained fetch/decode, architected registers and retirement.
and a single big pool of scoreboarded functional units, of course. the
advantage being that one thread could use many units. as opposed to a
static 8-core where each thread gets only the unit(s) in its core...
I think the main takehome from netburst-HT is that SMT needs to provide
more units, not just provide a new way for two threads to interfere.
regards, mark hahn.
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
