3 ms·
Turns out faster clocks don't help much if your logic isn't getting faster too. You do less work per cycle, while your cycle overhead remains fixed, resulting i
by ip26 6y ago
Turns out faster clocks don't help much if your logic isn't getting faster too. You do less work per cycle, while your cycle overhead remains fixed, resulting in less work done per unit time. If it wasn't for branch misprediction, you'd be better off with very deep pipes and slower clocks - see GPUs.
- ithkuil 6y agoI think the point of GP is that not every instruction makes use of the more complicated (4 input) adder, so not every instruction should have to pay for the latency cost associated. But at other pointed out this only makes sense if the ALU is the critical path and that having a two level adder significantly impacts the latency
- Taniwha 6y agoActually it's unlikely that this 4-input adder is in a general purpose ALU, usually they're directly in the cache access path (there are games you can apply to cache and TLB accesses if the low bits of that adder come out early), or in a separate addressing ALU which adds an extra clock to a load or store
- ithkuil 6y agoI assume they still count towards defining the shortest possible pipeline stage duration
- Taniwha 6y agoIt depends on how you split it up of course, but there's another cost, if you pipeline the address calculation you effectively make the cpu's pipe longer and more importantly increase the cost of a mispredicted branch - which is where we're all spending our time trying to mitigate these days