Also, counting of faulting instructions (do we double-count) can also
get funny so you may want to double check that.
What you can do is place an assert that compares the two differing
numbers so that you find the exact spot where the inst counts start to
diverge.
On Fri, Aug 24, 2012 at 9:47 AM, Anthony Gutierrez <atgut...@umich.edu> wrote:
> I know nops don't get counted and I'm taking that into account. The -I
> option exits based on thread[tid]->numInst, this is incremented in the same
> way as committedInst, i.e., neither count nops. I can't see why if I exit on
> thread[tid]->numInst == 1000, the stats file shows something different.
>
> The committedInsts (it's actually commitCommittedInsts) inside of
> commit_impl.hh are the insts for the commit stage and they are counted
> differently. I'm only looking at the CPUs committedInsts stat, which is only
> ever incremented when thread[tid]->numInst is also incremented as far as I
> can tell.
>
> For example, a simple run of stock gem5 gives:
>
> ./build/ALPHA/m5.opt configs/example/fs.py --cpu-type=detailed --caches
> --l2cache -I 20043
>
> sim_insts = 200045
> system.cpu.commit.commitedInsts = 200169 (These DO count nops as mentioned
> above)
> system.cpu.committedInsts = 200045 (These DO NOT count nops)
>
> I can't find where the discrepancy is coming from.
>
> -Tony
>
>
> On Fri, Aug 24, 2012 at 12:20 PM, Korey Sewell <ksew...@umich.edu> wrote:
>>
>> I'm saying that the nops may not get counted in committedInsts. Other
>> users have reported issues when comparing the committed instruction
>> count between CPU models and typically this is the problem.
>>
>> If you look in commit_impl.hh, around line 109, you'll see that
>> instDone() will not get called if the instruction is a nop or
>> prefetch.
>>
>> However, a couple of lines earlier committedOps and committedInsts can
>> be incremented in cases where instDone() isn't called.
>>
>> This may be the discrepancy that you are seeing.
>>
>> -Korey
>>
>> On Fri, Aug 24, 2012 at 8:04 AM, Anthony Gutierrez <atgut...@umich.edu>
>> wrote:
>> > This is the part of the code where the committedInsts get's incremented,
>> > so
>> > it should match up with that and has nothing to do with the ops.
>> >
>> > -Tony
>> >
>> >
>> > On Fri, Aug 24, 2012 at 10:16 AM, Korey Sewell <ksew...@umich.edu>
>> > wrote:
>> >>
>> >> Tony,
>> >> check the nop count. That might be the difference that you are seeing.
>> >>
>> >> -Korey
>> >>
>> >> On Thu, Aug 23, 2012 at 1:24 PM, Anthony Gutierrez <atgut...@umich.edu>
>> >> wrote:
>> >> > Hello,
>> >> >
>> >> > It seems that the number of committed instructions don't always match
>> >> > up
>> >> > with an instruction-based exit event, e.g., when using -I. The CPU's
>> >> > number
>> >> > of committedInsts can sometime be a few more or less than this value.
>> >> > I
>> >> > think I understand why the number can be more, if an exit event is
>> >> > scheduled
>> >> > when commit commits its 1,000th instruction, other events scheduled
>> >> > for
>> >> > the
>> >> > same tick can cause more instructions to be committed. Is that
>> >> > correct?
>> >> > But,
>> >> > why can the number of committed instructions ever be less than the
>> >> > number
>> >> > that triggers an exit event? I added this to the O3 cpu and dumped
>> >> > and
>> >> > reset
>> >> > stats after every exit:
>> >> >
>> >> > //inside of instDone()
>> >> > if (!(thread[tid]->numInst % 1000))
>> >> > exitSimLoop("1000 insts reached", 0);
>> >> >
>> >> > The number of committedInsts dumped after each exit varies but it
>> >> > usually
>> >> > within a few % of 1,000. However, it is rarely ever 1,000.
>> >> >
>> >> > Thanks,
>> >> > Tony
>> >> >
>> >> > _______________________________________________
>> >> > gem5-users mailing list
>> >> > gem5-users@gem5.org
>> >> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>> >>
>> >>
>> >>
>> >> --
>> >> - Korey
>> >> _______________________________________________
>> >> gem5-users mailing list
>> >> gem5-users@gem5.org
>> >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>> >
>> >
>> >
>> > _______________________________________________
>> > gem5-users mailing list
>> > gem5-users@gem5.org
>> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>>
>>
>> --
>> - Korey
>> _______________________________________________
>> gem5-users mailing list
>> gem5-users@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
>
> _______________________________________________
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
- Korey
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
