What is the fastest way to do this in c++ (Using OpenMP) - c++

Question

I have an algorithem that I can write in psedu code as follow:
for(int frame=0;frame <1000;frame++)
{
Image *img=ReadFrame();
mat processedImage=processImage(img);
addtompeg(processedImage);
}
ProcessImage is time consuming and would takes around 30 sec. ReadFrame an AddToMpeg are not slow but they need to be done sequentially (otherwise, fame 2 may be added to output before frame 1).
How can I parallelize it using OpenMP?
I am using opencv to readframe and addtompeg.

Answer 1

Technically, in OpenMP you may execute a portion of a for loop in the same order as if the program was sequential using the ordered clause (see section 2.8.7 here). Anyhow I would not suggest using this clause for two reasons:
a thread must not execute more than one ordered region in the same loop (which seems not to be your case)
in many implementations an ordered loop behaves much like a sequential loop, with detrimental effects on performance
Therefore what I would suggest in your case is to unroll the loop:
Image * img [chunk];
mat processedImage[chunk];
/* ... */
for(int frame = 0; frame < nframes; frame += chunk) {
#pragma omp single
{ /* Frames are read in sequential order */
for( int ii = frame; ii < frame + chunk; ii++) {
img[ii%chunk] = ReadFrame();
}
} /* Implicit barrier here */
#pragma omp for
for( int ii = frame; ii < frame + chunk; ii++) {
processedImage[ii%chunk] = processImage(img[ii%chunk]); /* Images are processed in parallel */
} /* Implicit barrier here */
#pragma omp single
{ /* Frames are added to mpeg sequential order */
for( int ii = frame; ii < frame + chunk; ii++) {
addtompeg(processedImage[ii%chunk]);
}
} /* Implicit barrier here */
}
The value of chunk depends mainly on considerations about memory. If you think that memory will not be a problem, then you can completely remove the outer loop and let the inner one go from 0 to nframes.
Of course care must be taken to correctly manage the remainders of the outer loop (which I have not shown in the snippet).

Answer 2

Building on the chunking idea of Massimiliano, a more elegant solution is to use the explicit tasking mechanism of OpenMP 3.0 and later (which means that it would not work with the C++ compiler from Visual Studio):
const int nchunks = 10;
#pragma omp parallel
{
#pragma omp single
{
mat processedImage[nchunks];
for (int frame = 0; frame < nframes; frame++)
{
Image *img = ReadFrame();
#pragma omp task shared(processedImage)
{
processedImage[frame % nchunks] = processImage(img);
disposeImage(img);
}
// nchunks frames read or the last frame reached
if ((1 + frame) % nchunks == 0 || frame == nframes-1)
{
#pragma omp taskwait
int chunks = 1 + frame % nchunks;
for (int i = 0; i < chunks; i++)
addtompeg(processedImage[i]);
}
}
}
}
The code might look awkward, but it is conceptually very simple. If it wasn't for the OpenMP constructs, it would be just like a serial code that buffers up to nchunks processed frames before it adds them in a loop to the output MPEG file. The magic happens in this block of code:
#pragma omp task shared(processedImage)
{
processedImage[frame % nchunks] = processImage(img);
disposeImage(img);
}
This creates a new OpenMP task that executes the two lines of code in the block. img and frame are captured by value, i.e. they are firstprivate, therefore it is not necessary for img to be an array of pointers. The producer task gives the ownership of img to the task and therefore the task has to take care of disposing the image object. It is important here that ReadFrame() allocates each frame in a separate buffer and does not reuse some internal memory each time (I've never used OpenCV and I don't know if this is the case or not). Tasks are queued and executed by idle threads waiting at some task scheduling point. The implicit barrier at the end of the single construct is such a scheduling point, therefore the remaining threads will start executing the tasks. Once that nchunk frames have been read or the end of the input has been reached, the producer thread waits for all queued tasks to be processed (that's what the taskwait is for) and then simply writes the chunks to the output.
Selecting the proper value of nchunks is important, otherwise some of threads might end up idling. If ReadFrame and addtompeg are relatively fast, i.e. reading and writing num_threads frames takes less time than processImage, then nchunks should be an exact multiple of the number of threads. If processImage can take varying amount of time, then you would need to set a really large value of nchunks in order to prevent load imbalance. In this case I would rather try to parallelise processImage instead and keep the processing loop serial.