tady je moc zajímavé povídání o CMT a srovnání se SMT :
http://www.google.cz/url?sa=t&source=we ... 1w&cad=rja
Simultaneous multithreading (SMT) architectures have the ability to execute instructions from multiple threads each cycle. These architectures effectively tolerate virtually all latencies observed by instructions in the pipeline. The additional latencies incurred by a clustered architecture are no different
A clustered multithreaded architecture, then, has the ability to exploit both thread-level parallelism and instructionlevel parallelism, yet still maintain high clock rates to maximize
overall throughput. Neither clustering or multithreading preclude traditional multiprocessing on the chip, which might include multiple clustered, multithreaded processors.
Clustered Execution Core :The first structures we
partition are the processor functional units and instruction
queues. The central instruction queue is equally split into
four smaller, 32-entry queues. Each instruction queue has
exclusive access to two integer functional units (one capable
of performing memory operations every other cycle) and
which can bypass values between each other with no additional
delays. The execution of a dependent instruction is
delayed by two cycles when executing in a different cluster
from a parent.
This configuration incurs performance losses
relative to the non-clustered processor from three sources:
(1) Dependent instruction execution delays — Because it
takes two cycles to wake up a dependent instruction in a different
queue cluster, the observed execution latency of the
producing instructions can be effectively lengthened.
(2) Load imbalance— An instruction will not issue when
all issue slots in its cluster have been allocated, even if resources
are free in another cluster.
(3) Increased queue conflicts — attempting to insert an
instruction into a full queue results in a queue conflict, preventing
further instructions from entering queues and stalling
preceding pipeline stages. This can occur even though entries
may be available in other instruction queues.
Front end clustering Front-end clustering divides the
pipeline stages which precede register renaming (fetch and
decode) into separate, four-wide pipelines. Each pipeline
has its own private instruction queue entries and functional
units (the register file, caches, and back-end pipeline stages
remain shared). Splitting the pipeline in this way can actually
be advantageous. Previously, a stall at any point in
the pipeline (for example, due to an instruction queue becoming
full) would cause instruction back-pressure and stall
fetch entirely. With a split processor front-end, a stall causes
back-pressure only in the pipeline in which it occurs. This
can prevent a single poorly behaved thread from impacting
the performance of the other threads in the processor, a problem
noted in prior research. However, the target pipeline
must be decided at fetch time, reducing our flexibility in assigning
instructions to different processor clusters. In addition
to several of the previously discussed performance issues,
a new form of renaming conflict is introduced with this
form of clustering.
(1)
Out-of-order renaming conflict — This is similar to
the previous renaming conflict, except that (a) the later instructions
can reach the renaming stage before the prior instructions
are renamed, and (b) the later instructions could
be stalled arbitrarily long waiting for the earlier instructions
to be renamed (if the other pipeline is stalled).
Because there is no direct communication between register
files, for a thread to switch pipelines its most recently
produced register values must be copied to the pipeline it
is switching to. We assume a specially allocated software
buffer is used to hold the intermediate values, and model this
swapping event by causing the thread switching pipelines to
issue 31 store instructions into its current pipeline, followed
by 31 load instructions into the other pipeline.
This is a conservative
mechanism for thread switching, but any realistic
mechanism will be slow, and this assumption forces us to
deal with that latency.
This scheme incurs two new performance costs:
(1) Increased register conflicts — With a single (logical)
register file, we run out of renaming registers only when all
registers in the machine are allocated. However, now that
registers are allocated separately from each register file, a register conflict occurs whenever either register file runs out of registers.
(2) Thread switch delays — When a thread switches the
pipeline it fetches into, it must now explicitly copy all integer
register state between the two independent register files.
to by mohlo lecos vysvětlovat o nevyrovnaném výkonu u BD....
\\Yuri: možnost B a E, respektive jejich kombinace...
. Vysledek se da predpokladat predem. 980x postavili v jedne hre (jeste nenarocne na CPU) a ne v enkodingu coz je k smichu jelikoz 980x opravdu neni urcen na hry a 2500 ho ve hrach roztrha. Kazdemu musi byt jasne odkud vitr vane 
