Hello, I would like to ask, in Gem5, will differences in the order of magnitude of operations such as Add affect factors such as latency or execution speed?

On 9/5/2023 9:30 AM, 中国石油大学张天 via gem5-users wrote: > Hello, I would like to ask, in Gem5, will differences in the order of magnitude of operations such > as Add affect factors such as latency or execution speed? I'm not sure how to answer that. Things depend so much on processor model and workload. If an operation is very common, and if other concurrent work can't hide it's latency, then overall execution time will be longer with a higher latency. Likewise, instructions per clock (speed) will suffer. But there are many factors. Remember a functional unit might be able to take a new add on every cycle, but might require (say) 5 cycles to complete each one. The *speed* is one per cycle, but the *latency* is 5. Then again, an FU might not be pipelined and its speed and latency would bot be one operation per 5 cycles. Yet, there might be more than one FU that handle adds, so there are other sources of parallelism. I think all we can offer is a kind of general insight like this. Plus I note that part of what matters in a particular workload is the dependencies between instructions. If the whole rest of the computation requires the result of that add, then things will be slower than if there are multiple things going on. And all of this assume the out of order processor model. An entirely in-order processor will tend to be be more strongly affected by high latency of a common operation. None of this is particular to gem5 - it's general principles of computer architecture. Maybe others can refine / add to this ... HTH -- EM