On Fri, Feb 12, 2010 at 10:37 AM, stephane eranian
<eran...@googlemail.com>wrote:

> On Fri, Feb 12, 2010 at 5:17 PM, heechul Yun <heechul....@gmail.com>
> wrote:
> > I'm experimenting performance counter to find deterministic events.
> >
> > I originally thought that the number of retired instructions will be the
> > same for every run of the program with the same input. However, it was
> not.
> >
> > The following is the result with the 'task' example provided in libpfm4
> > package.
> >
> >  ./task -e "inst_retired" gcc
> > gcc: no input files
> >              1252403 inst_retired
> >
> >  ./task -e "inst_retired" gcc
> > gcc: no input files
> >              1252405 inst_retired
> >
> >
> > As you can see above, they are different for each run. I only enabled
> 'user'
> > mode counting to exclude any perturbation.
> >
> I would not call this a major perturbation, it's more like noise.
> One way this might be introduced is when you are interrupted very
> near the kernel/user boundary, for instance as you are about to
> leave the kernel. I would not worry about those. It will be more
> significant as you add more events or as you compete with
> other users on the system.
>
> Interestingly, "inst_retired:stores" seems to give deterministic number.

/task -e "inst_retired:stores" gcc
gcc: no input files
              108856 inst_retired:stores

/task -e "inst_retired:stores" gcc
gcc: no input files
              108856 inst_retired:stores

/task -e "inst_retired:stores" gcc
gcc: no input files
              108856 inst_retired:stores


As you said, however, If I used multiple events, it starts to give largely
non-deterministic numbers.

./task -e "inst_retired:stores,inst_retired:loads" gcc
gcc: no input files
               95890 inst_retired:stores (scaled from 56.57% of time)
              321715 inst_retired:loads (scaled from 43.43% of time)

 ./task -e "inst_retired:stores,inst_retired:loads" gcc
gcc: no input files
               47850 inst_retired:stores (scaled from 33.86% of time)
              363727 inst_retired:loads (scaled from 66.14% of time)

The question are,
1) why "inst_retired:stores" is deterministic -- if it is true?
2) if there are more than two events or users to use performance counter, is
it impossible to guarantee reliable (or deterministic) number ?

Best

Heechul


> >         fds[0].hw.exclude_kernel = 1;
> >         fds[0].hw.exclude_idle = 1;
> >         fds[0].hw.exclude_hv = 1;
> >
> >
> > What is the reason of this unexpected non-determinism?
> >
> > Best Regards,
> >
> > Heechul
> >
> >
> >
> ------------------------------------------------------------------------------
> > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> > http://p.sf.net/sfu/solaris-dev2dev
> > _______________________________________________
> > perfmon2-devel mailing list
> > perfmon2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
> >
> >
>
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Reply via email to