Re: General profiling approaches

> [People have been profiling C code for 30 years quite successfully.
> Perhaps this would be a good time to go find out how they've done so.
> -John]


The best way i know of that a C or any other code can be profiled is to
translate the code into assembly, marking begining and the end of the
assembly code coresponding to each line of code / statement in C and
then inserting time tracking code into this generated assembly code.
This method will allow minimal effect of profiler code on the profiled
code. Now, if i was to insert a C profiler code into C profiled code
and then compile the result, the resulting assembly code will look
nothing like the compiled profiled code without the profiler code.


My initial question in this thread was mostly intended to reveal the
profile limitation using a single language, that is profiling C using
C, not profile C using asm.


In physics the unsertanty principle poses limitation on measuring of
events, since the process of measuring in itself intoduces
perturbation, and therefore the measurement of an event is limited to a
given acuracy. 2*pi*p*x=h x is position p is momentum h is planks
constant.


Insertion of the profiler code also introduces perturbation of the
profiled code, the limiting case, which would be using assembly
language to profile assembly language, introduces perturbations such as
instruction que being different than in original code, plus the use of
cpu cache would also be probably altered.


I am a physisssist, not a computer engineer, hence i can not attach
any numbers to the above formulated limitation, but i was hoping
someone here may be able to.


it seems to me that there are 2 issues which are not accounted for in
todays top of the line profilers:
1) Error introduced by introduction of profiler code in assembly code
of the profiled code. This results in small error
2) Error introduced by introduction of profiler code of the same level
of abstraction as the profiled code. This introduces larger error than
in case 1 since the resulting assembly code looks very different than
the assembly of profiled code alone.


The second issue only exists for compilers which try to optimize the
code. Case 2 will be the same as case 1 if the compiler blindly
translates the input language into asm 1 statement at the time, hence
the compilation process is not altered by existance of profiler code.


Any thought about this?


[These are all techniques that have been used many, many, many times
over the past 40 years or so, and they're not the only ones. Unix
systems use a statistical method that doesn't change the object code
at all, for example. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.