That’s very helpful, thanks a lot!

Best,
Farhad

On Mar 15, 2021, at 1:32 PM, Giacomo Travaglini 
<giacomo.travagl...@arm.com<mailto:giacomo.travagl...@arm.com>> wrote:

EXTERNAL EMAIL:

Yeah, this is a quirkiness of gem5. I have tried to address it some time ago 
[1]; I should probably go back and rebase the patchset.

Basically the numOp, by being a Counter (and not a Stat) doesn't get reset 
every time you reset stats.
So the numOp is the total number of ops since the beginning of the simulation, 
whereas committedOp is the real indication of committed ops  in the region of 
interest (as it can be reset).

My advice is to simply look at committedOp if you just want to know executed 
ops in the region of interest

Kind Regards

Giacomo

[1]: https://gem5-review.googlesource.com/c/public/gem5/+/25303

-----Original Message-----
From: Farhad Yusufali 
<farhad.yusuf...@mail.utoronto.ca<mailto:farhad.yusuf...@mail.utoronto.ca>>
Sent: 15 March 2021 17:22
To: Giacomo Travaglini 
<giacomo.travagl...@arm.com<mailto:giacomo.travagl...@arm.com>>
Cc: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>>
Subject: Re: Simulated vs Committed Ops

Hi Giacomo,

I only execute a single workload every time I run a simulation, so there are no
interactions between different workloads.

I do reset my stats at the beginning of the region of interest of my workload
though (using a pseudo-instruction).

Thanks,
Farhad



On Mar 15, 2021, at 12:56 PM, Giacomo Travaglini
<giacomo.travagl...@arm.com<mailto:giacomo.travagl...@arm.com> 
<mailto:giacomo.travagl...@arm.com> >
wrote:

EXTERNAL EMAIL:

Hi Farhad,

Quick question: are you resetting the stats between one workload
and the other?

Kind Regards

Giacomo



-----Original Message-----
From: Farhad Yusufali via gem5-users <gem5-
us...@gem5.org<mailto:us...@gem5.org> <mailto:gem5-users@gem5.org> >
Sent: 15 March 2021 16:26
To: gem5-users@gem5.org<mailto:gem5-users@gem5.org> <mailto:gem5-users@gem5.org>
Cc: Farhad Yusufali 
<farhad.yusuf...@mail.utoronto.ca<mailto:farhad.yusuf...@mail.utoronto.ca>
<mailto:farhad.yusuf...@mail.utoronto.ca> >
Subject: [gem5-users] Simulated vs Committed Ops

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/> <http://cpu.cc/>
<http://cpu.cc<http://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


IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

_______________________________________________
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

Reply via email to