Is there an instruction histogram tool for Windows 7?

Is there an instruction histogram tool for Windows 7 running
on an Intel XEON processor?

The program might run at a high priority and see what
in instruction was about to be executed for the process or
processes that are being traced.

I don't know to know the order of instructions, but I'd
like to know about how many branches compared to about
how many adds, compared to how many multiplies, character
movement, encryption, decryption instructions are a being
used by a given process.

It would also be nice to find out how many times a process
relinquished control (i.e., waiting for I/O)

Mark F wrote:
Is there an instruction histogram tool for Windows 7 running
on an Intel XEON processor?

The program might run at a high priority and see what
in instruction was about to be executed for the process or
processes that are being traced.

I don't know to know the order of instructions, but I'd
like to know about how many branches compared to about
how many adds, compared to how many multiplies, character
movement, encryption, decryption instructions are a being
used by a given process.

It would also be nice to find out how many times a process
relinquished control (i.e., waiting for I/O)

Even in a HLL group, you're not likely to find much interest
in profiling things.

There's some kind of tool here, and in general, people interested
in profiling might be found in the Intel forums (there are a couple
different ones). Both Intel and AMD have documents describing
how to optimize code for their respective processors, so
anyone interested in performance, may visit there at
some time or another. Intel has their forums, and I don't know
if AMD has anything similar on their site. They don't have the
staff or money for anything superfluous any more.

https://software.intel.com/en-us/art...pment-emulator

My most memorable story on profiling, is from work. Even though
I'm a hardware guy, I was extolling the virtues of profiling
program execution (because one of our staff had written
a particularly nice profiler for its time). The software
guy I was jawing with, wasn't convinced they were
worthwhile.

Anyway, I return to my desk, and a couple hours later, he races
into my cubicle to say "I found something". He found a chunk
of code which was a copy/paste error into his source, and
that block of code was doing data movement, and eating
25% of his execution time. The profiler he tested, showed
the hotspot, and a sense of curiosity got him to look
at the source. He couldn't figure out how the code
got there, but was quite willing to delete it. I don't
know if I "made a believer" of him, but he sure seemed
excited by the discovery. And one of his friends wrote
that profiler, and that guy deserves the praise for how
well it worked.

So even if you're "Gods gift to programming" and never
make mistakes, you'd be surprised what you can learn
sometimes with these tools.

Best practice normally, is to concentrate on specific
blocks of code. Maybe most of your code is mundane stuff
and not expected to loop or otherwise misbehave. And most
of the code does not affect the execution time. However,
a specific routine may need profiling at the instruction
level, just to see if there is any way to improve it.

One technique, is to set a breakpoint after each instruction,
and the instrumentation code the breakpoint triggers, records
the current program counter on the stack, and what instruction
executed. That would be a non-statistical approach to profiling,
but it prevents real-time execution (it's very slow but
precise). Otherwise, you can set a timer and take statistical
samples of where a program is right now and what it's doing.
You can also set breakpoints after each HLL code chunk (i.e.
right after the line number logging line) and record as a function
of the HLL you're using (maybe WinDBG does that?). Or, set a
breakpoint after each subroutine, and just collect a log
of subroutines. There are plenty of approaches, and too many
half-finished tools for any one human to keep track of.

It's like debuggers. I see lots of things that might work
like GDB, but they're not finished. Half of them, I couldn't
even get them to load my sample code and run it. And I think
the last time I used GDB, it couldn't tell me anything about
SSE4.2 instructions in some code I was looking at (i.e. my
modern processor supported and used such code in Linux, and
gdb couldn't print out what the instruction was).
So while there are tools, there are also limitations.
Be prepared to waste a lot of time experimenting.

Years ago, I was given (by AMD), an instruction level simulator
for one of their processors. And had great fun timing some
assembler sample code, to estimate whether their processor would be
fast enough. Intel at the time, was willing to accept my
source code, but they would not give me the tool to run
the code for myself. So I have had some experience in the past
doing this sort of thing, but haven't done anything current.

And for any commercial SDK suite, be prepared to pay a princely sum.
Nobody is going to make good tools generating this
level of detail, completely for free. If you want free,
you might use something like this.

http://www.ollydbg.de/

Paul