SDE disassembly and MS windows disassembly discrepencies

[perfwise]

Hi,
I was working on a project in Windows and using MS tools to generate disassembly to correlate the "mix" output of SDE with my program's disassasembly from MS with "link /dump /all" which includes the function specifications etc. I noted that the addresses of the blocks of code annotated in SDE are 16B, 0x10, off from that of SDE. I observed this with the latest version of SDE in windows. When trying to correlate blocks of SDE to those of windows in an automated fashion I noted this was a problem, since instr addresses don't match. Additonally, rip relative address instructions in MS were different, in instruction bytes in SDE, driven by this difference in the RIP of the instruction and that offsets from the RIP of SDE generated different instruction opcode bytes.

Are you aware of this and if not can you look into it. Thanks..

Perfwise..

[MarkC_Intel]

Hi, I'm not aware of an issue like this. When running in SDE, the addresses mix shows are where the image loaded; which is not necessarily the same as the location recommended by the image when it is on disk. I will take a look though.
Regards,
Mark

[TimP]

I've been wrestling with a similar question: do the alignments seen by SDE, as they affect the branches taken, reflect what happens on actual hardware? I have no evidence they don't, my efforts to align data so as to avoid taking remainder loops in vectorized code appear to be heeded both under SDE and when executing on hardware. Yet, we wonder why the performance of SSE and AVX code is the same, for practical purposes, even though the instruction counts reported by SDE are way different.

[bronxzv]

I assume you're comparing 128-bit AVX code with 128-bit SSE code, right? Are you testing on actual SNB hardware?

[TimP]

Prior to testing, there was an assumption that AVX-256 should generally have a performance advantage over SSE, when alignments are suitable.
The SNB desktop CPU has some large performance advantages over Core I7, but not much due to ISA change.
Large gains are expected with future MKL library versions, taking advantage of AVX.

[bronxzv]

I'll be glad to test it when I have access to a SNB desktop, for a compute bound kernel it looks rather disapointing to have the same performance (due to L1D access bottleneck, particularlystores ?), maybe the extra YMM registers in 64-bit mode will help a bit the scaling of 256vs 128 ?