You'll want to take a look at the stats files and see what's going on. There's a lot of microarchitectural detail that needs to be checked in order to make the fair comparison.
My guess is that one model is counting nops and one isnt, thus messing up the CPI counts. You can also check L1 cache miss rates, branch predictor accuracy, and things of that nature. Also note the latencies for different types of instructions and % of different types of instructions for your workload. For instance, by default if you are only charging 1 cycle for a multiply in InOrder but charging 8 cycles in O3, then that can make for a unfair comparison. On Mon, Apr 30, 2012 at 2:31 PM, Eyal Yaacoby <[email protected]> wrote: > Hi all, > > As I continued running workloads, I've noticed that inorder runs faster > than O3. > I'm running PARSEC workloads on Alpha FS. > Both processors run with identical frequency, use the default L1,L2 > caches, and a simple memory system. > > command lines used: > ./build/ALPHA/gem5.opt ./configs/example/fs.py -n 1 --caches --l2cache > --script=<script> --cpu-type=inorder > ./build/ALPHA/gem5.opt ./configs/example/fs.py -n 1 --caches --l2cache > --script=<script> --cpu-type=detailed > > > On a particular workload, O3 reaches an IPC of 1.55 (which seems > reasonable), while the inorder CPU reaches a whooping 2.04 - which doesn't > seem reasonable to me.. > What can cause this behavior? > > > Thanks in advance, > Eyal Yaacoby > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > -- - Korey
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
