Profiling my code

**Kempelen** · 07-08-2008

Hi,
I use MINGW and I have a program made by me in which I have included my own profile system. I can't use gcc profile because I have thread and gprof dont support thread althoug of the two thread I have, I only want to measure one of them.

What I do is a system where a function is call: the first instruction in the function is a call to start the function time counter. When exits, a call is made to stop time function. If in between, the caller time counter is stopped, put in a stack, and a start a new counter. When exit the time counter is stopped, then put again the caller time counter on.
Something like this:

Code:

function a1(int x) {
   PROFILE_START("a1");
    if  (x==1) {
        a2(x); // a1 counter is stopped,when return from a2 is started
        PROFILE_STOP("a1");
        return ;
    } else {
        x+=1;
    } 
    PROFILE_STOP("a1");
}

function a2(int x) {
    PROFILE_START("a2");
    x += 5;
    PROFILE_STOP("a2");
}

I use clock() to measure all this. do you find something wrong with this approach? do you think the result are reasonble?
My test show coherent results, but I am not sure if the system is detailed or good timer. do you think small function are measured correctly?

thx all.

**zacs7** · 07-08-2008

clock() only has second resolution*, that's a bit small in most cases for profiling. A system specific high-res timer will give better results.

Well I was wrong

Still, it doesn't have to be accurate, and may even have a res of 1 second

-- ie a 1Hz CPU

**audinue** · 07-08-2008

See:
http://cboard.cprogramming.com/showthread.php?t=104873

Btw, what is the meaning of profiling using gprof or something???

**matsp** · 07-08-2008

Originally Posted by zacs7

clock() only has second resolution, that's a bit small in most cases for profiling. A system specific high-res timer will give better results.

Actually, clock() is better than 1s, generally in the 1-10ms range.

It will probably not be good enough for this sort of measurement.

If we restrict the usage to gcc/x86, then you could use the RDTSC instruction as inline assembler. See: http://en.wikipedia.org/wiki/RDTSC

--
Mats

**Kempelen** · 07-08-2008

Originally Posted by matsp

Actually, clock() is better than 1s, generally in the 1-10ms range.

It will probably not be good enough for this sort of measurement.

If we restrict the usage to gcc/x86, then you could use the RDTSC instruction as inline assembler. See: http://en.wikipedia.org/wiki/RDTSC

--
Mats

This actually looks like a precise system, but in order to convert results to seconds I need to know processor frecuency. Does is not problem. I measure cycles between two seconds (using sleep), but , what about if the machine has more than one processor? how this work?

**Elysia** · 07-08-2008

RDTSC is not recommended, due to multi-core issues.
Use appropriate API instead (such as QueryTickCounter on Windows).

**matsp** · 07-08-2008

Originally Posted by Kempelen

This actually looks like a precise system, but in order to convert results to seconds I need to know processor frecuency. Does is not problem. I measure cycles between two seconds (using sleep), but , what about if the machine has more than one processor? how this work?

Each processor(core) has it's own TSC - so if you have more than one processor(core), then they will have (potentially) different TSC values. For AMD processors on Windows, you can use the "dual core optimizer" to ensure that they are reasonably in sync. The worst case scenario would be if a thread switches from one processor(core) to another. This can lead to the time being off by a rather large amount. There is no easy solution to this problem.

Another option, but it has noticeably higher overhead, would be to use the Windows QueryPerformaceCounter system call. That will not be as precise in granularity, and it may still use TSC, but I believe it's less likely to fluctuate depending on for example which processor you are using at the time of asking. There's a sister call to this function, which I believe is called QueryPerformanceCounterFrequency to find what the current frequency is.

--
Mats

**zacs7** · 07-08-2008

> such as QueryTickCounter on Windows
Making up functions now are we?

**matsp** · 07-08-2008

Originally Posted by Elysia

RDTSC is not recommended, due to multi-core issues.
Use appropriate API instead (such as QueryTickCounter on Windows).

I wrote a slightly longer answer. Both techniques are valid and have their advantages. RDTSC is MUCH faster (as it completes, not counting synchronization instructions) in a couple of clock-cycles. However, it is also less precise. It's a balance. If profiling single functions with few lines of code is the main target, then the RDTSC would be a preferred solution, even if it "misses" sometimes (you can most likely filter those few occurrances out and still get valid statistics) [1]

For functions that take longer time (several microseconds or more), system calls that may block (these obviously fall into "the microseconds or more" category when blocking), and such, then QueryPerformanceCounter is definitely a preferred method.

--
Mats

**Salem** · 07-08-2008

Create a separate test which allows you to profile one thread at once (or the thread in question).

gprof in general will tell you a lot more than your homebrew approach, which will riddle the code with your profiling inserts.

**Elysia** · 07-08-2008

Originally Posted by zacs7

> such as QueryTickCounter on Windows
Making up functions now are we?

Yup.
Couldn't remember the name on top off my head and didn't want to bother looking it up, so QueryTickCounter it is

Thread: Profiling my code

Thread Tools

Search Thread

Display

Profiling my code

Similar Threads

Profiling for c code in eclipse

Obfuscated Code Contest: The Results

Obfuscated Code Contest

Interface Question

Who will map the scan code (inserted by VKD_Force_keys) to virtual key code?