Precise Events

[k_sarnath]

From what I learn from Intel manual is that , upon counter-overflow on a "precise event" -- the CPU will update the IP, Registers onto the "DS Save" area. So, the performance monitoring application can only know the "instruction" that caused the counter overflow... but not all other instructions that contributed for filling up the sample..... Right?

So, the sample count shown against a particular instruction -- is merely an indicator that the instruction is pssibly responsible for that precise event..... Am I right? Is that a right way of interpreting the numbers?

[David_A_Intel1]

So, sounds like two questions.

First, sampling is a statistical approach to profiling, which reduces the overhead of monitoring execution. Samples are collected when the counter register overflows and minimal information is collected in the interrupt service routine. Attributing samples to modules and functions occurs during post-processing.

Second, "precise events" are a function of the processor hardware, specifically, the performance monitoring unit (PMU). Some events are defined as "precise" (by the processor) and so the processor stops execution immediately AFTER the instruction that caused the overflow. A non-precise event may not stop execution for several (up to 48 on some older processors) instructions, causing what we refer to as "event skid" (see definition in the VTune analyzer help's glossary). Thus, if you see a memory type event sample on a non-memory instruction, don't be surprised! Instead, look at the flow of instructions, prior to that instruction, for a memory-accessing instruction. Precise events will not "skid" more than one instruction.

Hope that helps!

[k_sarnath]

Thanks for your time.....

Coming to your 2nd answer --- Let us say the counter is programmed such that an overflow occurs after 10000 events.... It is quite possible that 9999 events occured in one section of my code and the 10000th event occured in another section --- This will lead me to interpret that all 10000 events occured only in the second section...... Well... Thats not fool-proof.... Thats my point.One needs to be a bit more careful while interpreting these numbers....

Am I right?

[David_A_Intel1]

The reality is that, if 9999 times out of 10000 an event is occurring in section one, most samples will be collected in section one and NOT section two.

The only time what you described could cause confusion is IFF you sampled at the same rhythm that the one event was occuring within the second section. And, since you can't control what else is occurring in the system, the likelihood is "slim to none."

Sampling is a "statistical" approach to profiling, and as such, it generalizes what is happening and situations like what you describe tend to be reflected accordingly. That is, if the event really is happening most of the time in one section of code, that's what the sampling will show. It will NOT highlight the situation that is NOT significant.

[k_sarnath]

Yeah, I guess you are right.... Statistics...should model the reality.... hopefully...
Thanks for your time.