By using the "timing" cpu, you are effectively using something that is like an idealized 1-wide, in-order cpu model. So the maximum possible IPC would be one and with cache accesses, etc it should be expected to be much lower than one.
For relative comparisons, especially papers not looking explicitly at core architecture, it's probably ok. Be aware that compared to an out of order cpu model, in-order cpu models have no way of overlapping/hiding memory latency with other useful work (like in the shadow of a miss to an L2 cache). So the relative performance differences vs an out of order cpu model may be skewed. On Thu, Feb 28, 2013 at 5:46 PM, Rodrigo Reynolds Ramírez < [email protected]> wrote: > Hello everyone, > > I am working with cache replacement policies and I want to compare the IPC > between these algorithms, I am using a --cpu-type=timing. For comparing > the performance I am using the IPC, I am calculating it as > system.cpu.committedInsts/system.cpu.numCycles, > but the values I got are different from papers and the ones I got from > other simulator. > > The timing model is valid for calculating the IPC? > I have read in the forum some people talking about low IPC for h264, > actually all my spec2006 benchmarks have a low IPC. > > Thanks in advance > Rodrigo > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
