On Tue, Mar 9, 2010 at 3:06 PM, stephane eranian <eran...@googlemail.com>wrote:

> On Tue, Mar 9, 2010 at 11:21 AM, heechul Yun <heechul....@gmail.com>
> wrote:
> > I am very sorry for the prior message which is sent accidentally during
> > writing.
> > I used perf_examples/task.c and performed the following simple
> measurement
> > for 'ls' command several times.
> >
> > ./task ls  -e "BR_INST_RETIRED"
> >               686804 BR_INST_RETIRED   <-- first execution
> >               686803 BR_INST_RETIRED   <-- second execution
> >               686805 BR_INST_RETIRED   <-- third execution
> > .
> That's nothing major. It is in the noise.
>
> > ./task ls  -e "MEM_STORE_RETIRED"
> >                  226 MEM_STORE_RETIRED
> >                  250 MEM_STORE_RETIRED
> >                  217 MEM_STORE_RETIRED
> > ./task ls  -e "INST_RETIRED"
> >              2830093 INST_RETIRED
> >              2830099 INST_RETIRED
> >              2830097 INST_RETIRED
> >
> > On the other hand, "inst_retired:stores" on core2duo always gave me the
> same
> > number.
>
> Most likely it is because stores occur less frequently than branches. There
> are
> always interruptions going on when you measure, even just at the user
> level.
>
>
Do you mean that even though I exclude kernel level events ( exclude_kernel
= 1) the interrupt handler portion of the events are counted?  Could you
briefly explain what kind of interruptions destroy determinism?

I'm looking for deterministic event source to implement deterministic thread
scheduling similar to the recent paper --
http://people.csail.mit.edu/mareko/asplos073-olszewski.pdf. The basic
assumption of this approach is we do have reliable deterministic event
source for a program execution (they used "inst_retired:stores" and I did
the same). Therefore, it is important to know if the assumption is wrong in
commodity hardware.

Best



> > Best
> > Heechul
> > On Tue, Mar 9, 2010 at 1:14 PM, heechul Yun <heechul....@gmail.com>
> wrote:
> >>
> >> ./task ls  -e "BR_INST_RETIRED"
> >>               686804 BR_INST_RETIRED
> >>               686803 BR_INST_RETIRED
> >>               686805 BR_INST_RETIRED
> >>
> >> On Tue, Mar 9, 2010 at 12:03 PM, stephane eranian <
> eran...@googlemail.com>
> >> wrote:
> >>>
> >>> On Tue, Mar 9, 2010 at 5:03 AM, heechul Yun <heechul....@gmail.com>
> >>> wrote:
> >>> > Hello
> >>> > I've used "inst_stored:stores" event to get a deterministic number
> for
> >>> > a
> >>> > given program execution on my Core2Duo workstation.
> >>> > Recently, I got a brand new i7 machine with 8 cores, but I found that
> >>> > "inst_stored:stores" is not supported in the i7.
> >>> Correct.
> >>>
> >>> > I've tried a couple of other events such as "inst_retired",
> >>> > "BR_INST_RETIRED", and "MEM_STORE_RETIRED" but none gave the
> >>> > deterministic
> >>> > result.
> >>>
> >>> What do you mean?
> >>> Could you show me the counts you obtain and with what command?
> >>>
> >>> > What other events can be used as deterministic event sources?
> >>> > The following is detected PMU model using examples/check_events on my
> >>> > i7
> >>> > computer.
> >>> > Detected PMU models:
> >>> > [14, nhm, "Intel Nehalem"]
> >>> > [15, nhm_unc, "Intel Nehalem uncore"]
> >>> > [16, ix86arch, "Intel X86 architectural PMU"]
> >>> > [50, perf, "perf_events generic PMU"]
> >>> > Best
> >>> >
> >>> >
> >>> >
> ------------------------------------------------------------------------------
> >>> > Download Intel&#174; Parallel Studio Eval
> >>> > Try the new software tools for yourself. Speed compiling, find bugs
> >>> > proactively, and fine-tune applications for parallel performance.
> >>> > See why Intel Parallel Studio got high marks during beta.
> >>> > http://p.sf.net/sfu/intel-sw-dev
> >>> > _______________________________________________
> >>> > perfmon2-devel mailing list
> >>> > perfmon2-devel@lists.sourceforge.net
> >>> > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
> >>> >
> >>> >
> >>
> >
> >
>
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Reply via email to