Latency is the amount of time to handle a single operation, whereas bandwidth is the overall rate at which operations can be completed. A basic example is putting out a fire using a bucket brigade: Latency would be the amount of time for one bucket to get from the water source to the fire, whereas whereas bandwidth would be the rate at which buckets would be poured onto the fire.

a. sra $a0, $s4, 10

b. sw $t3, 20($s5)

We would need arrows from after lw's MEM stage to the beginning of the first add's EX stage, and from after the first add's EX stage to the beginning of the second add's EX stage.

a. RAW: a→b, b→d, c→d

b. WAR: b→c

c. WAW: a→c

Even without long-term stalls, there are still short-term stalls due to data dependencies and control dependencies. By switching rapidly between threads, a fine-grained multithreaded processor lengthens the time between checking which instructions to dispatch next in a particular thread; thus, instructions are more often ready when its turn comes.

For example, suppose we have two threads executing “lw $t0, 0($s0)” followed by “addi $t1, $t0, 1” using a classic 5-stage RISC pipeline. If the pipeline focuses on one thread at a time, the second instruction would need to stall for one instruction while lw loads $t0 to be used by addi. So the processor would take three cycles to process these two instructions in one thread, then three cycles ofr the second thread, for a total of six cycles. With fine-grained multithreading, the processor would execute one thread's lw, then the other's, then the first thread's addi, then the other's. There would be no need to stall, since the first thread's value for $t0 would be available by the time the processor got back around to its addi, so it would take four cycles, not six as with a single-threaded processor.

With fine-grained multithreading, the processor considers dispatching instructions from only one thread in each cycle, though it rotates between which thread it considers after each cycle. With simultaneous multithreading, the processor will consider dispatching instructions from varied threads in each clock cycle. This leads to the possibility that instructions from two different threads (or more threads) will be dispatched in exactly the same cycle, which cannot happen with fine-grained multithreading.

When the branch predictor predicts that the branch will be taken, the processor needs to know which instruction will be next. Even a simple branch often adds a number to the PC to compute the target; so being able to load from a cache can help to start fetching the next instruction even before the addition has taken place. The delay to determine the branch's target is particularly problematic, though, when the branch target comes from a register (such as with jr or jalr in MIPS); a branch target buffer can attempt to predict the register's value from the previous time a branch occurred, allowing instructions to be fetched and executed before the target is finally confirmed.