Re: General profiling approaches

Chris F Clark <cfc@shell01.TheWorld.com> schreibt:


> "fermineutron" <free4trample@yahoo.com> writes:
>
>> 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.
>
> Well, that's not the best way, not even close. You don't need to
> measure that much if you have a good model of the hardware (see
> below). You only need to know which paths through the code are taken.


[...]


> However, even without such techniques, even simple C profiling by
> inserting C statements into the source can be done without permuting
> the execution too much. My recollection is that the INSIGHT tool from
> Parasoft did just that. Again, I don't believe they put start/stop
> blocks around each statement, but you don't need to. When you are
> profiling a program, you don't care about the relative cost of the two
> statements "a = 1; b = 2;", you care about how decision logic (if and
> loop statements) and routine calls affect the execution. Therefore,
> you only need measurements at the "branches" and the "calls".
> Everything else you can compute off-line, if you need to compute it at
> all.


This is mostly what I wanted to say. AFAICT, measurements in physics
and profiling computer programs aren't done for the same reasons, at
least most of the time. In physics, or electrical engineering, which
I know a little more about, you are usually interested in the exact
value. It has to be correct because this affects how you design the
rest or your circuit or whatever. When you profile a computer
program, exactness doesn't really concern you. Usually you only want
to know what makes your program slow, where it spends most of its
time. You may find out that a certain function is called much more
often than you anticipated when you wrote it. So you optimize said
function and everything is well. Or you see that malloc and free are
called very often, so you try not to create as many temporary objects.
For these tasks, the measurements of the profiler just have to be in
the same ballpark as the actual values.


--
Wolfram Fenske

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