A few questions regarding hardware events

[T_C]

Greetings,

• Looking at the below link, what exactly is the difference between non-precise and precise monitoring? Might seem a silly question- but why would anyone ever use unprecise monitoring??

http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/~amplifierxe/pmn/events/about_branch_execution_performance_tuning_events.html

• In the below link what is the difference between a "call" and "non-call"? Would one of these refer to polymorphic virtual methods?
• In the same below link, I would like to see the value for the event "INDIRECT_NON_CALL" and I can see a mask. This appears to be some sort of bit manipulation device. How exactly do I see the value of this event counter? Where/what do I do with the mask?

http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/~amplifierxe/pmn/events/br_misp_exec.html

In short, I am trying to work out which event counters I need to look at to observe indirect branch mispredictions for virtual calls. I am presuming I am close with these "INDIRECT" event counters?

[David_A_Intel1]

Hi T C:

For precise vs non-precise, you don't always get a choice.  Most events are non-precise!  Case in point, the link you referenced.  There may not be any precise equivalent events available from the performance monitoring unit of the processor.

[T_C]

MrAnderson (Intel) wrote:

Hi T C:

For precise vs non-precise, you don't always get a choice.  Most events are non-precise!  Case in point, the link you referenced.  There may not be any precise equivalent events available from the performance monitoring unit of the processor.

Hi- thanks for that. Don't suppose you have any insight in to the other 2 questions?

Thanks in advance.

[Bernard]

As far as I was able to understand NON_CALL could be related to branch to the target which does not contain any function call.

DIRECT_NEAR_CALL could mean branch to the target in the same segment and execution of the call instruction.

Machine code level and underlying CPU microarchitecture probably does not "understand"  virtual functions.

[Bernard]

>>>In the same below link, I would like to see the value for the event "INDIRECT_NON_CALL" >>>

Usually virtual function will be called indirectly through the pointer.So in this case of virtual function call I would suggest to measure INDIRECT_NEAR_CALL.

In assembly it should like this:

call dword ptr [eax] ; eax contains a pointer to VTBL

[T_C]

iliyapolak wrote:

>>>In the same below link, I would like to see the value for the event "INDIRECT_NON_CALL" >>>

Usually virtual function will be called indirectly through the pointer.So in this case of virtual function call I would suggest to measure INDIRECT_NEAR_CALL.

In assembly it should like this:

call dword ptr [eax] ; eax contains a pointer to VTBL

So how do I use these "masks" to see the additional event counters?

I wish intel would just show all of the raw columns in the GUI!

[Bernard]

T C wrote:

Quote:

iliyapolak wrote:

>>>In the same below link, I would like to see the value for the event "INDIRECT_NON_CALL" >>>

Usually virtual function will be called indirectly through the pointer.So in this case of virtual function call I would suggest to measure INDIRECT_NEAR_CALL.

In assembly it should like this:

call dword ptr [eax] ; eax contains a pointer to VTBL

So how do I use these "masks" to see the additional event counters?

I wish intel would just show all of the raw columns in the GUI!

If I am not wrong those events should have corresponding MSR registers.

[David_A_Intel1]

@T C, instead of making you program masks, we typically enumerate the counters, e.g., MEM_LOAD_UOPS_LLC_HIT_RETIRED

• MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HIT
• MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HIT_PS
• MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HITM
• MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HITM_PS

[T_C]

MrAnderson (Intel) wrote:

@T C, instead of making you program masks, we typically enumerate the counters, e.g., MEM_LOAD_UOPS_LLC_HIT_RETIRED

• MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HIT
• MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HIT_PS
• MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HITM
• MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HITM_PS

Hi, what do you mean by this exactly?

[David_A_Intel1]

@T C, you said, "So how do I use these "masks" to see the additional event counters?"  You don't need to use masks, the additional counters are enumerated in the VTune Amplifier XE tool.  Unless I am totally missing your point?

[T_C]

MrAnderson (Intel) wrote:

@T C, you said, "So how do I use these "masks" to see the additional event counters?"  You don't need to use masks, the additional counters are enumerated in the VTune Amplifier XE tool.  Unless I am totally missing your point?

Could you please explain what you mean by "enumerated"?

I have an event counter called MEM_LOAD_UOPS_LLC_HIT_RETIRED and it has a value. Other than that I have no idea how I need to get the various "subset" counters- except you tell me they are enumerated?

Enumerated just means things are listed one by one- hence ive no idea how this applies in this context.

[David_A_Intel1]

Right, so if you want the XSNP_HIT sub-counter, the SDM says it has a mask value of '2'.  Only, you don't have to know that or use it, because VTune Amplifier XE allows you to select MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HIT.

[T_C]

MrAnderson (Intel) wrote:

Right, so if you want the XSNP_HIT sub-counter, the SDM says it has a mask value of '2'.  Only, you don't have to know that or use it, because VTune Amplifier XE allows you to select MEM_LOAD_UOPS_LLC_HIT_RETIRED.XSNP_HIT.

Massive apologies- I now understand why you were confused when I asked what did you mean. Yes for that particular example they are "enumerated", ie they are all on display. However, let us take BR_MISP_RETIRED:

http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/~amplifierxe/pmw_dp/events/br_misp_retired.html

I only have BR_MISP_RETIRED.ALL_BRANCHES_PS. I do not have any of the other enumerated options in my VTune results..... 

[David_A_Intel1]

Okay, what processor are you using?  For my Sandy Bridge-based system, I see these events: