- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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..
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..
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Regards,
Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ?

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page