Hello all, I’m trying to figure out the difference between two stats - simOps and system.cpu.commit.committedOps. I’m using a 4-wide single DerivO3CPU CPU, running serial workloads (i.e. no threads). In src/cpu/o3/cpu.cc<http://cpu.cc>, in the instDone function, I found the following code that is executed every time an instruction is committed:
thread[tid]->numOp++; thread[tid]->numOps++; committedOps[tid]++; As you can see, both committedOps and numOp is incremented once for every op committed. In the same file, in the totalOps function, the numOp values across different threads are accumulated to return a total op count for the entire core: template <class Impl> Counter FullO3CPU<Impl>::totalOps() const { Counter total(0); ThreadID size = thread.size(); for (ThreadID i = 0; i < size; i++) { total += thread[i]->numOp; } return total; } Finally, in src/cpu/base.hh, in the BaseCPU class, there is a function, numSimulatedOps that coalesces op counts across CPUs: static Counter numSimulatedOps() { Counter total = 0; int size = cpuList.size(); for (int i = 0; i < size; ++i) total += cpuList[i]->totalOps(); return total; } This total value is used to generate the simOps stat. To summarize, every time an op is commited, both committedOps and numOp are incremented. committedOps is dumped out using the system.cpu.commit.committedOps stat, while numOp is accumulated across both threads and CPUs and then dumped out using the simOps stat. Since I’m using a single CPU with a single thread, I would expect both stats to be identical, however they end up being vastly different (sometimes by over a factor of 10) (simOps is usually larger). Does anyone have any insight into why this could be happening? Thanks, Farhad
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s