data alignment problem?

[vtuneuser]

I have a case that Vtune displayed a source line with very high timer value from the time-basing sampling. The source line was deferencingpointers of pointers of a struct "node" passed as a function parameter as the following,

node->field4 = node->field1->field3+node->field2->field4;

where field1is a pointer to another struct andfield2 ia a pointer to"node" struct itself. The field4 was 44 bytes offset from the beginning of the struct, the following assembly code was shown as the hotspot from Vtune,

add ebx DWORD PTR [ecx+02ch]

was adding those two operands at the left hand side of "=" sign. I am not sure what exact problem is, is it a alignment problem on the calling stack or because of the 44 bytes? what is the next step tofind outthe real problem ? I printfed the address of node->field2->field4 and it wasdivisible by 4, I am using the compiler optimization flag, so I thought the alignment may not the problem? any suggestion?

another hotspot was a few line after the above line was

mov DWORD PTR [epb+02ch], ecx

is it because the stack parameter was aligned but not the field that was 44 bytes away from the beginning of the parameter?

thanks.

[David_A_Intel1]

Hi, again,vtuneuser!

I don't think you can infer anything about the cause of the hotspot from the samples and instruction to which they were attributed. There are two reasons:

1. "Event skid" causes the event to be attributed to an instruction that follows the actual instruction that caused the event. In the case of time-based sampling, I suspect there is "skid" but for a different reason than EBS.
2. TBS simply tells you where there is significant activity, not why. You need to start using EBS to try to determine why. You might start by using the Tuning Assistant in the Sampling Wizard and selecting the Primary Performance Events group (can't remember the exact name, but "Primary" is in there somewhere).

Right now, with the data you have, you simply know that this code section is taking a significant amount of time to execute, relative to the rest of the code.

Regards,

[jim_dempsey]

Can you expand the assembler code around the C++ statement in question including the assembler code for the statement preceeding the instruction? Then send in that snipit of code (include the counts).

>>

another hotspot was a few line after the above line was

mov DWORD PTR [epb+02ch], ecx

is it because the stack parameter was aligned but not the field that was 44 bytes away from the beginning of the parameter?

<<

In the above, ebp is a pointer to the stack frame. The stack frame is always DWORD aligned and depending on options may additionaly be Paragraphed aligned. The move instruction is writing the contents to a location on the stack frame (a local variable).

What is likely happening is your program enters the subroutine and the header code for the subroutine allocates stack space for local variables (this is virtualy no overhead as it simply subtracts a constant from the stack pointer). However, the stack variables are un-initialized. This too is no problem - yet. Some time into your routine you have the write to location [epb+02ch] which may be the very first occurance of accessing this location. (either read or write). If that location of memory has not been cached then you will see a higher number of hits in the sample counts.

Is the higher than what you expect frequency of hits a significant portion of the overall time of the function (e.g. > 0.1%, > 1.0%, > 10%)?

Jim Dempsey