3 ms·
A superscalar machine should still be able to benefit from loop unrolling by issuing the instructions for multiple iterations in parallel (though this is more h
by kd0amg 14y ago
A superscalar machine should still be able to benefit from loop unrolling by issuing the instructions for multiple iterations in parallel (though this is more hardware-dependent than I like to think about when coding). The rollback machinery in branch speculation hardware can only handle a limited number of branches, so a loop with a very small body running on a machine with a very deep pipeline could spend a lot of time waiting on confirmations of correct branch predictions.
- Tuna-Fish 14y ago> by issuing the instructions for multiple iterations in parallel Unless you actually do something in the loop body, all modern superscalar HW would be bottlenecked on the writes, making multiple iterations impossible. For example, SNB has 5 main execution ports -- two agus, 3 alus, and it can do either of 2 reads or 1 read + 1 write in a single cycle. This means that if you are storing something every cycle, for each cycle you can do 3 instructions without slowing down the loop. Also, if the jump instruction is immediately preceded by the alu instruction that generates the flags for it, they get fusioned into a single instruction, meaning you don't need to count the jmp as an instruction. > The rollback machinery in branch speculation hardware can only handle a limited number of branches This used to be more of a problem before modern PRF cpus -- with PRF, recovery from branch miss is much cheaper (it's essentially the copy of 17 8-bit pointers), so Sandy Bridge and later can typically handle more in-flight branches than their pipeline length, so confirmations of branch predictions shouldn't ever stall you unless you use division to get the flags or something.