Hi, That depends on the definition of idle cycle. Some say that idle cycles don't include cache misses because there exists some instructions in the pipeline. With such definition, idle cycles are related to thread stalls due to I/O, network, ...
You have to check how idle cycles is incremented in gem5 On 3/31/14, Fernando Endo <[email protected]> wrote: > Hello, > > On the other hand, if a system has two cores, and only one thread is > executing, should the IPC of a core represent the busy portion of the app > or the overall IPC including the idle cycles? > > Im my opinion, the current definition may be linked to what hardware perf > counters do. Any expert among us to explain that? > > Thanks in advance, > > -- > Fernando A. Endo, PhD student and researcher > > Université de Grenoble, UJF > France > > > > 2014-03-26 23:15 GMT+01:00 Tiago Mück <[email protected]>: > >> Hi, >> >> At /src/cpu/o3/cpu.cc we can see that the IPC is defined like this: >> >> totalIpc >> >> .name(name() + ".ipc_total") >> >> .desc("IPC: Total IPC of All Threads") >> >> .precision(6); >> >> totalIpc = totalCommittedInsts / numCycles; >> >> >> But, according to a previous post on the list ( >> http://comments.gmane.org/gmane.comp.emulators.m5.users/11513), " >> *numCycles*" accounts for only busy CPU cycles, so shouldn't IPC be >> either "*totalCommittedInsts / (numCycles+idleCycles)*" or >> "*totalCommittedInsts >> / (numCycles+idleCycles+quiescCycles)*" ? >> >> If my understanding is correct, using the current formula may lead to >> similar IPCs for tasks with very different cache miss rates for instance. >> >> Thanks. >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > -- Regards, Mahmood _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
