Profiling openMP

General OpenMP discussion

Profiling openMP

Postby hildy » Mon Jul 07, 2008 5:15 am

I wonder which tools you guys use to profile your parallellized code. Do you have any tips and tricks on good ways of profiling a code which have been modified from serial to parallel. I both want to profile the performance of the parallelized code, and be able to compare it with the original serial code. Even investigate the costs of overhead of openMP vs gain from openMP with different numbers of processors.
Prefferably free profiling software.
Thanks /Hildy
hildy
 
Posts: 14
Joined: Mon Jun 30, 2008 2:39 am

Re: Profiling openMP

Postby ejd » Mon Jul 07, 2008 7:23 am

The question has been asked before and I am not sure that anyone really answered it. It would help if you would give the type of hardware, OS, and OpenMP implementation that you are using. Many of the vendors that support OpenMP have profile tools that are part of their products. Several of these profilers can also work quite well on code generated by gcc. Most of the vendors have free trials and several now provide their code for free - including (shameless plug) Sun. There are also numerous tools available on the web from various universities.
ejd
 
Posts: 1025
Joined: Wed Jan 16, 2008 7:21 am

Re: Profiling openMP

Postby hildy » Tue Jul 08, 2008 5:22 am

I use gcc and trolltech Qt. I mainly use the "for" directive for parallelisation. I run on ubuntu 8.04 64-bits with a Intel core2 Quad 4-core cpu. I want to find a software that is able to profile a run and give me a output of how well the different function calls used and divided the work among the different cores.
I reckon that this kind of profiling would be crucial for openMP programmers so somebody around here must have a knowledge of the usable profiling tools out there.
hildy
 
Posts: 14
Joined: Mon Jun 30, 2008 2:39 am

Re: Profiling openMP

Postby hildy » Thu Jul 17, 2008 1:46 am

By the way Is there any good debuggers for finding race conditions and other parallelistion related bugs?
hildy
 
Posts: 14
Joined: Mon Jun 30, 2008 2:39 am

Re: Profiling openMP

Postby djo35 » Fri Jul 18, 2008 7:10 am

Race conditions are notoriously difficult to track down. I may be old fashioned here (I'd love to try ejd's snazzy profiler majigs) but I find the best way to spot this stuff is to add OMP one loop at a time with low thread numbers (and plenty of print statements). It could be that multiple bugs are playing havoc with each other so this is a sure fire way to catch them. gdb is great and ddd can speed bug tracking up no end - and if you're using C Electric Fence can prevent many headaches.

As for profiling, gprof with gcc works pretty well (compare serial and parallel runs) . You just need to put some thought into which functions are being run in parallel and their various thread initialisation / memory issues.

Dan
djo35
 
Posts: 11
Joined: Wed May 28, 2008 8:24 am

Re: Profiling openMP

Postby ejd » Mon Jul 21, 2008 7:38 am

There are a couple of ways to do profiling. One way is to add instrumentation at compile time. This has the disadvantage of requiring a special compile and flag for instrumentation. It can also have a fairly high overhead cost and can get in the way of what you are trying to measure. There are several university projects out on the web that do this kind of profiling. Another approach, is a time sampling approach. At some increment of time, the program can be stopped and looked at and then restarted. This would of course slow it down quite a bit, so generally it is not stopped, but looked at from another process. This lets the program behave pretty much like it would if it were not being sampled. This too is not without it's problems. If the sampling rate is too high, then you can get a ton of data and fill up your disk. If it is too low, then you might not see some things that are of interest.

Dan (djo35) has suggested a couple of possible approaches. I have to say that I am sort of old fashion too and use print statements a lot. That said, I don't recommend it for trying to find races conditions. The main issue with parallel programming is timing. I have looked at programs (that I didn't write) that have run for years "correctly" that "all the sudden failed". The problem was a race condition that had gone undetected for all that time. Using a good tool for finding race conditions and profiling is essential. It can reduce your development time and number of problems substantially.

That said, I am afraid that I am not in the position to recommend compilers or tools. I work for Sun Microsystems and we produce compilers, performance libraries, profiling tools, and threading tools that I would love to have you try. They work on Solaris and some versions of Linux (and we are trying to increase the Linux versions our code works on). The code is free and you can get a support contract if you want to. However, these tools may or may not be what you need and what I am trying to do here is answer questions about OpenMP and not push any particular vendor products. So all I can say, is look at the OpenMP web site and the compunity web site for links to various tools; check Yahoo, Goggle, or whatever your favorite search tool is for keywords like OpenMP and profiling and see what you get; and keep checking back to see if someone else has added any more suggestions here.
ejd
 
Posts: 1025
Joined: Wed Jan 16, 2008 7:21 am


Return to Using OpenMP

Who is online

Users browsing this forum: Google [Bot] and 1 guest