Below you will find the winning entries by problem for the Threading Challenge 2011.  Please feel free to review and join us in the forum dedicated to each problem to discuss.

Master Level

Problem 1 - P1:M1 Masyu Puzzle

1st Place:    john_e_lilley         Code     Write-up
2nd Place:   Diao Rui                 Code     Write-up
3rd Place:    akki                       Code     Write-up

Comment on the Masyu Puzzle Dedicated Forum

Problem 2 - P1:M2 Tiling Rectangles

1st Place:    akki                       Code      Write-up
2nd Place:   denghui0815         Code      Write-up
3rd Place:    protocolocon        Code      Write-up

Comment on Tiling Rectangles Dedicated Forum

Problem 3 - P1:M3 Parallelized Parser and Formula Interpreter

1st Place:    akki                       Code     Write-up
2nd Place:   john_e_lilley         Code     Write-up
3rd Place:    denghui0815         Code     Write-up

 Comment on the Parallelized Parser and Formula Interpreter Dedicated Forum

Apprentice Level

Problem 1 - P1:A1  Maze of Life

1st Place:    VoVanx86             Code
2nd Place:   krivyakin              Code
3rd Place:    jmfernandez        Code

Comment on Maze of Life Dedicated Forum

Problem 2 - P1:A2  Sums of Consecutive Primes

1st Place:    dotcsw                 Code
2nd Place:   VoVanx86            Code
3rd Place:    jmfernandez       Code

Comment on the Sums of Consecutive Primes Dedicated Forum

Problem 3 - P1:A3  Running Numbers

1st Place:    dotcsw                Code
2nd Place:   vdave                 Code
3rd Place:    kolkir                 Code

Comment on the Running Numbers Dedicated Forum

Intel® Threading Building Blocks is used in wide range of applications. If performance makes sense and multi core platform is used, TBB is good thing to be added to C++ program. Network applications are usually highly-loaded as they process huge amount of traffic and processing time constraints are high. This article is intended to show how TBB can be used in network packet processing software, improving its productivity and processing time.

For a sample project I've created a simplified Network Router emulator. Network Router is a device that routes and transmits IP (Internet Protocol) packets in local area network (LAN). It connects several PCs, provides them access to Internet and internal network. The device has several internal network interfaces and one external.

The sample project emulates Network Router logic. It provides the following functionality:

• Input packets from file - the application is just a model so there is no need for real interconnection with network interface. Reading from file emulates real reading from network interface.
• NAT - Network Address Translation. The router has only one external IP address, but packets should be delivered to several internal devices behind the router. NAT allows port and IP mapping from external to internal and vice versa.
• IP routing - delivering packets to appropriate router NIC (Network Interface Controller) according to destination IP.
• Bandwidth management - some traffic is real time and it's critical to deliver these packets as quick as possible (e.g. voice over IP). The VoIP protocols maintain telephone conversation and delays would degrade quality. The router can prioritize these critical packets so they can be processed quicker.

I've created two versions of Network Router: serial and parallel. The latter uses Intel® Threading Building Blocks. I'll describe how TBB was used in the project and will provide performance results of the program parallelization.

Network Router implementation

Network router emulator gets packets from file and processes them. Packet processing includes Bandwidth management, NAT translation and IP routing. Packets are processed by several program modules. These processing modules are ordered sequentially, like in assembly line. This is common composition of packet processing application. Input file is a text file, each line represents one IP packet. There is separate thread that reads packets by big chunks.

Intel® TBB has tbb::pipeline class that provides high level framework for such kind of program structure. It has filters that process packets on each stage. Each packet goes through the pipeline and is processed step by step by its filters. One packet is processed sequentially - from first filter to second, than third, etc. However processing of one packet is independent from another, so filters can operate in parallel.

Network Router scheme

Main function:

#include <iostream> 
#include <sstream>
#include <fstream>
#include <vector>
#include <algorithm>
#include <ittnotify.h>
#include <tbb/pipeline.h>
#include <tbb/concurrent_hash_map.h>
#include <tbb/atomic.h>
#include <tbb/concurrent_queue.h>
#include <tbb/compat/thread>
// Redirects calls to "new" and "delete" to TBB thread safe allocators
#include <tbb/tbbmalloc_proxy.h>

using namespace tbb;
using namespace std;

class bandwidth_manager_t;
class network_adress_translator_t;
class ip_router_t;
class compute_t;
typedef vector<packet_trace_t> packet_chunk_t;

int chunk_size = 1600;
concurrent_queue<packet_chunk_t> chunk_queue;
atomic<bool> stop_flag;

int main(int argc, char* argv[])
{
	ip_addr_t external_ip;
	nic_t external_nic;	
	nat_table_t nat_table;	// NAT table   
	ip_config_t ip_config;	// Router network configuration 					
	int ntokens = 24;	
	
	get_args (argc, argv);	
    ifstream config_file (config_file_name);

    if (!config_file) {
        cerr << "Cannot open config file " << config_file_name << "\n";
        exit (1);
    }		
	if (! initialize_router (external_ip, external_nic, 
                            ip_config, config_file)) exit (1);	
	
	thread input_thread(input_function);

	// packet processing objects
	bandwidth_manager_t bwm;	
	network_adress_translator_t nat(external_ip, external_nic, nat_table);
	ip_router_t ip_router(external_ip, external_nic, ip_config);		

__itt_resume();
	bool stop_pipeline = false;	
	
	parallel_pipeline(ntokens,		
		make_filter<void, packet_chunk_t*>(		// Input filter
			filter::parallel,
			[&](flow_control& fc)-> packet_chunk_t*{				
				
				if (stop_pipeline){					
					fc.stop();
				}				
				packet_chunk_t* packet_chunk = new packet_chunk_t(chunk_size);
					
				if(!chunk_queue.try_pop(*packet_chunk)){				
					if (stop_flag) {
						stop_pipeline = true;
					}
				}				
				return packet_chunk;
			}
		)&	// Bandwidth manager filter
		make_filter<packet_chunk_t*, packet_chunk_t*>(		
			filter::parallel,
			[&](packet_chunk_t* packet_chunk)-> packet_chunk_t*{								
				
				for(int i=0; i<packet_chunk->size(); i++){
					packet_trace_t packet;
					packet = (*packet_chunk)[i];				
					
					if (packet.nic == empty){
						break;
					}
					else{
						bwm.prioritize(packet);									
						compute_t compute;
						compute.work();						
					}										
				}
				std::sort(packet_chunk->begin(), packet_chunk->end(),
							packet_comparator);
				return packet_chunk;	
			}
		)&	// NAT filter
		make_filter<packet_chunk_t*, packet_chunk_t*>(	
			filter::parallel,
			[&](packet_chunk_t* packet_chunk)-> packet_chunk_t*{

				for(int i=0; i<packet_chunk->size(); i++){	
					packet_trace_t packet;

					packet = (*packet_chunk)[i];					
					if (packet.nic == empty)
						break;
					else{				
						nat.map(packet);
						compute_t compute;
						compute.work();	
					}
				}				
				return packet_chunk;
			}
		)&	// IP routing filter
		make_filter<packet_chunk_t*, packet_chunk_t*>(		
			filter::parallel,
			[&](packet_chunk_t* packet_chunk)-> packet_chunk_t*{			

				for(int i=0; i<packet_chunk->size(); i++){						
					packet_trace_t packet;
					packet = (*packet_chunk)[i];
					
					if (packet.nic == empty)
						break;
					else{				
						ip_router.route(packet);
						compute_t compute;
						compute.work();	
					}
				}				
				return packet_chunk;
			}
		)&	// Output filter
		make_filter<packet_chunk_t*, void>(	
			filter::parallel,
			[&](packet_chunk_t* packet_chunk){														
				
				for(int i=0; i<packet_chunk->size(); i++){						
					packet_trace_t packet;
					packet = (*packet_chunk)[i];	
					compute_t compute;
					compute.work();	

					if (packet.nic == empty)
						break;
				}	
				// No output is required , just drop packets
				delete packet_chunk; 
			}
		)
	);	
__itt_pause();

	cout << "\nAll packets are processed\n\n";		
	return 0;
}

First part is "preparation" - creating objects, reading command line, opening files and initializing. Configuration file contains router interfaces info. Objects bwm, nat and ip_router are packet processing objects. They use containers nat_table and ip_config for storing NAT and IP tables.

The core component of Network Router is pipeline. It is implemented using tbb::parallel_pipeline() function, that takes number of tokens and list of filters as arguments. The element of work that is passed through the pipeline is of type packet_chunk_t. Parameter ntokens controls maximum number of concurrently processed elements. It has value 24 because the project was tested on 24-core machine and making it bigger wouldn't make an effect.

Pipeline filters perform some work execution, particularly packet processing in this application. Filters can be serial or parallel. This mode is controlled by filter parameter that is filter::parallel for all filters. This means that any filter can process some elements at the same time.

First filter extracts packet chunk from chunk_queue and passes it to second filter. Second filter performs bandwidth management operations on each packet from chunk. bwm module assigns priorities to packets according to protocol. Then packets in chunk are sorted by priority. This allows critical traffic to be processed as early as possible.  Subsequent filters make NAT mapping and IP routing. Last filter is output, but for simplicity real output is not done. Packets are just dropped.

Packet chunk is used as pipeline token because it's big enough. If single packets were passed through pipeline there would be too much transitions between threads, and overhead would be bigger than positive effect.

The __itt_resume() and __itt_pause() functions are used by Intel® VTune^TM Amplifier XE that was used for performance measurements. These API functions mark the beginning and the end of area of interest.

Object compute of type compute_t makes workload for CPU. It just performs additional computations to simulate computing in real systems. The application doesn't perform the entire job needed for processing and routing packets in real life network equipment. It is just model framework of real application, so there is not enough CPU usage. Method compute_t:: work()starts computing "N Queens" algorithm.

Input file opening and reading is a job of separate thread. It is instantiated using std::thread class that is a part of new upcoming C++ 11 standard.

Serial implementation

To understand effect from parallelization a serial version was created. It has similar structure. The only difference is that parallel_pipeline is replaced with simple while loop.

Network router serial scheme

While loop (replacing parallel_pipeline):

__itt_resume();
	bool stop = false;

	while (!stop){
		packet_chunk_t packet_chunk(chunk_size);
		
		if(!chunk_queue.try_pop(packet_chunk)){				
			if (stop_flag) {
				stop = true;
			}
		}		
		
		for(int i=0; i < packet_chunk.size(); i++){
			packet_trace_t packet = packet_chunk[i];;			
			bwm.prioritize(packet);	
			compute_t compute;
			compute.work();									
		}
		std::sort(packet_chunk.begin(), packet_chunk.end(), packet_comparator);
		for(int i=0; i < packet_chunk.size(); i++){
			packet_trace_t packet = packet_chunk[i];				
			nat.map(packet);
			compute_t compute;
			compute.work();		
			ip_router.route(packet);				
			compute.work();							
			compute.work();								
		}
	}
__itt_pause();

There are four calls of compute.work() - the same number as in TBB version. This is going to be the most CPU time consuming function, so it's fair to have same number of calls to it.

Data structures

Input file has the following format:

eth3 104.44.44.10 10.230.30.03 4003 5003 ftp
eth3 104.44.44.10 10.230.30.03 4003 5003 rtp
eth0 134.77.77.30 104.44.44.10 2004 4003 sip
eth3 104.44.44.10 10.230.30.03 4003 5003 http

Each line represents one packet. It has network interface, source, destination IP and port, protocol. Packet is stored in packet_trace_t structure:

typedef struct {
	nic_t nic;			// network interface where packet arrived
	ip_addr_t destIp;		// destination IP
	ip_addr_t srcIp;		// source IP
	port_t destPort;		// destination port
	port_t srcPort;		// source port 
	protocol_t protocol;	// protocol type (rtp, ftp, http, sip, etc)
	int priority;			// packet priority
} packet_trace_t;

typedef concurrent_hash_map<port_t, address*, string_comparator> nat_table_t; 
typedef concurrent_hash_map<ip_addr_t, nic_t, string_comparator> ip_config_t; 
typedef vector<packet_trace_t> packet_chunk_t;
concurrent_queue<packet_chunk_t> chunk_queue;

void input_function(){	
    ifstream in_file (in_file_name);
    if (!in_file) {
        cerr << "Cannot open input file " << in_file_name << "\n";
        exit (1);
    }
	stop_flag = false;	
	
	while(in_file.good()){			
		packet_chunk_t packet_chunk(chunk_size);
								
		for(int i=0; i<chunk_size; i++){
			packet_trace_t packet;
			in_file >> packet;					
			packet_chunk[i] = packet;			
		}
		chunk_queue.push(packet_chunk);			
	}
	stop_flag = true;
}

Performance measurements

The goals of this project were to achieve good performance and scalability by using TBB. For measurements the following setup was used:

CPU: 4 processors Intel® Xeon X7460, 2,66 Ghz, 24 physical cores total
RAM: 16 GB
OS: Microsoft Windows Server® Enterprise 2008 SP2
Workload: input file: 113405 packets (5,1 MB)
Measurement tool: Intel® VTune^TM Amplifier XE 2011
Analysis type: Concurrency with default settings

It's seen that CPU time is similar. This is sum of CPU times of all cores of the system. But elapsed time is very different. This is clock time that the application takes for processing. In serial version it is near the value of overall CPU time. In TBB version it is 19 times less. So the application worked 19 times faster.

Average number of utilized cores for TBB version is 20.5 and most of the processing time all 24 were used. This demonstrates that application is scalable enough and can use almost all cores on multi-core system.

The results provided show good performance results for TBB-based application. However keep in mind the following conditions:

1) There were used Amplifier XE API functions __itt_resume() and __itt_pause() that bound measured area. The result show performance of tbb::parallel_pipeline for TBB version and while loop for serial version. Measurements of overall application work will give a little bit different results.

2) Simulated job was used to utilize CPU. The compute_t class computes algorithm of "N queens" task. Real processing is different.  If there would be not enough job for CPU, file input would consume relatively more time. So in real application scalability and performance gain can be worse.

Conclusion

Below you will find some of the submitted entries by problem for Phase 1 of the Threading Challenge 2010.  Please feel free to review and join us in the forum dedicated to each problem to discuss.

Master Level

Problem 1 - Hosoya Index             Comment on dedicated forum for Hosoya Index

Entry Submitted by Michael_Uelschen:     Code        Write-up

Entry Submitted by sukhaj:     Write-up

For early adopters we introduced support of AVX in Intel® Software Development Emulator [2], it allows you to run and check functional correctness of the code with the actual AVX instructions before hardware is available.

Today we are adding another useful piece to help those who may not be able to use new tools supporting AVX in their current development environment but plan to migrate in the future or are using a software platform which is not supported by Intel SDE. These software developers can still start programming with Intel AVX using intrinsics.

Here we are providing the C and C++ header file which emulates Intel AVX intrinsics. The AVX emulation header file uses intrinsics for the prior Intel instruction set extensions up to Intel SSE4.2. SSE4.2 support in your development environment as well as hardware is required in order to use the AVX emulation header file.

To use simply have this file included:

#include "avxintrin_emu.h"

Instead of usual:

#include <immintrin.h>

One can also create alternative immintrin.h file (which in turn includes avxintrin_emu.h) to avoid an intrusive change to the source base and then simply switch between real AVX code generation and emulation via alternating the path to include directories.

Emulation header is primarily targeting UNIX type of environments, and was tested on such with GCC and Intel C/C++ compilers. We have a strong support with other tools (compilers, assemblers and SDE) on Microsoft Windows platform, but this header file can still be used on Windows, if desired, with Intel Compiler.

Note that the AVX emulation header file is designed to allow functional correctness of an AVX implementation and not recommended for long-term usage or release in a final product. Once your development environment and hardware supports AVX, we recommend that you switch to the real AVX intrinsic header file.

Although we did our best to debug it, this file must not be considered a reference functional implementation of AVX instructions or even bug-free. Please see the current version's limitations and caveats in the beginning of the file. Please let us know about the issues you faced using it.

Example

#include "avxintrin_emu.h"  // #include <immintrin.h>

void saxpy( float a, const float* x, const float* y, float* __restrict z, size_t len )
{
    size_t i = 0;
    __m256 a_ = _mm256_set1_ps( a );

    for ( size_t len16_ = len & -16; i + 16 <= len16_; i += 16 )
    {
        __m256 x1_ = _mm256_loadu_ps( x + i );
        __m256 x2_ = _mm256_loadu_ps( x + i + 8 );

        __m256 y1_ = _mm256_loadu_ps( y + i );
        __m256 y2_ = _mm256_loadu_ps( y + i + 8 );

        x1_ = _mm256_mul_ps( x1_, a_ );
        x2_ = _mm256_mul_ps( x2_, a_ );

        x1_ = _mm256_add_ps( x1_, y1_ );
        x2_ = _mm256_add_ps( x2_, y2_ );

        _mm256_storeu_ps( z + i     , x1_ );
        _mm256_storeu_ps( z + i + 8 , x2_ );
    }

    for ( ; i < len; ++i )
        z[i] = x[i] * a + y[i];
}

References

[1] Intel AVX - http://software.intel.com/en-us/avx/

[2] Intel Software Development Emulator - http://software.intel.com/en-us/articles/intel-software-development-emulator/

Begin Thread Function ()
  Initialize ()
  BEGIN CRITICAL SECTION 1
    UpdateSharedData1 ()
  END CRITICAL SECTION 1
  DoFunc1 ()
  BEGIN CRITICAL SECTION 2
    UpdateSharedData2 ()
  END CRITICAL SECTION 2
  DoFunc2 ()
End Thread Function ()

you may write in this way

Begin Thread Function ()
  Initialize ()

  BEGIN CRITICAL SECTION 1
    UpdateSharedData1 ()
    DoFunc1 ()
    UpdateSharedData2 ()
  END CRITICAL SECTION 1

  DoFunc2 ()
End Thread Function ()

We decided to carry out some experiments and see if and how the theory meets the practice and what performance gains we may expect. For this purpose we made a test program that contains some functions with various synchronization implementations.

Here is what the program does: we calculate two sums (msum1, msum2). As this is performed in parallel, we need to protect these variables during the write. Like it was shown in the example from the article "Managing Lock Contention: Large and Small Critical Sections", we use two critical sections at first. Then we unite these sections into one critical section. Note that after this step the function of calculating the n-th root gets included into the section - it is a rather resource-intensive operation. Then we carry out some experiments.

Description of functions with various implementations of synchronization:

Foo1 - We use two critical sections:

#pragma omp critical
{
  msum1 += m1;
}
double m2 = pow(m1, 1.0 / h);
#pragma omp critical
{
  msum2 += m2;
}

Foo2 - We use one critical section. The n-th root is calculated inside the critical section:

#pragma omp critical
{
  msum1 += m1;
  double m2 = pow(m1, 1.0 / h);
  msum2 += m2;
}

Foo3 - We use one critical section. The n-th root is calculated outside the critical section:

double m2 = pow(m1, 1.0 / h);
#pragma omp critical
{
  msum1 += m1;
  msum2 += m2;
}

Foo4 - We use atomic operations (atomic directive):

#pragma omp atomic
msum1 += m1;

double m2 = pow(m1, 1.0 / h);

#pragma omp atomic
msum2 += m2;

Foo5 - We use reduction directive:

#pragma omp parallel for reduction(+:msum1, msum2)
...
msum1 += m1;
double m2 = pow(m1, 1.0 / h);
msum2 += m2;

The full text of the program is given below. You may also download the project for Visual Studio 2005.

#include <stdio.h>
#include <tchar.h>
#include <windows.h>
#include <math.h>
#include <omp.h>
#include <iostream>
#include <float.h>

class Timing {
public:
  void StartTiming();
  void StopTiming();
  double GetUserSeconds() const {
    return value;
  }
private:
  DWORD_PTR oldmask;
  double value;
  LARGE_INTEGER time1;
};

void Timing::StartTiming()
{         
  SetThreadAffinityMask(::GetCurrentThread(), 0);
  QueryPerformanceCounter(&time1);
}  

void Timing::StopTiming()
{  
  LARGE_INTEGER performance_frequency, time2;
  QueryPerformanceFrequency(&performance_frequency);
  QueryPerformanceCounter(&time2);  
  SetThreadAffinityMask(::GetCurrentThread(), oldmask);
  value = (double)(time2.QuadPart - time1.QuadPart);
  value /= performance_frequency.QuadPart;
}

double **CreateArray(ptrdiff_t w,
                     ptrdiff_t h)
{
  double **array = (double **)
    malloc(w * sizeof(double *));
  if (array == NULL)
    throw std::exception("Error allocate memory");
  for (ptrdiff_t x = 0; x != w; ++x)
  {
    array[x] =
      (double *)malloc(h * sizeof(double));
    if (array[x] == NULL)
      throw std::exception("Error allocate memory");

    for (ptrdiff_t y = 0; y != h; ++y)
      array[x][y] = (rand() % 100) / 100.0;
  }
  return array;
}

double Foo1(double **array,
            ptrdiff_t w, ptrdiff_t h)
{
  double msum1 = 0;
  double msum2 = 0;

  #pragma omp parallel for
  for (ptrdiff_t x = 0; x < w; x++)
  {
    double m1 = 1;
    for (ptrdiff_t y = 0; y != h; ++y)
      m1 *= array[x][y];

    #pragma omp critical
    {
      msum1 += m1;
    }
    double m2 = pow(m1, 1.0 / h);
    #pragma omp critical
    {
      msum2 += m2;
    }
  }

  return msum1 + msum2;
}

double Foo2(double **array,
            ptrdiff_t w, ptrdiff_t h)
{
  double msum1 = 0;
  double msum2 = 0;

  #pragma omp parallel for
  for (ptrdiff_t x = 0; x < w; x++)
  {
    double m1 = 1;
    for (ptrdiff_t y = 0; y != h; ++y)
      m1 *= array[x][y];

    #pragma omp critical
    {
      msum1 += m1;
      double m2 = pow(m1, 1.0 / h);
      msum2 += m2;
    }
  }

  return msum1 + msum2;
}

double Foo3(double **array,
            ptrdiff_t w, ptrdiff_t h)
{
  double msum1 = 0;
  double msum2 = 0;

  #pragma omp parallel for
  for (ptrdiff_t x = 0; x < w; x++)
  {
    double m1 = 1;
    for (ptrdiff_t y = 0; y != h; ++y)
      m1 *= array[x][y];

    double m2 = pow(m1, 1.0 / h);
    #pragma omp critical
    {
      msum1 += m1;
      msum2 += m2;
    }
  }

  return msum1 + msum2;
}

double Foo4(double **array,
            ptrdiff_t w, ptrdiff_t h)
{
  double msum1 = 0;
  double msum2 = 0;

  #pragma omp parallel for
  for (ptrdiff_t x = 0; x < w; x++)
  {
    double m1 = 1;
    for (ptrdiff_t y = 0; y != h; ++y)
      m1 *= array[x][y];

    #pragma omp atomic
    msum1 += m1;

    double m2 = pow(m1, 1.0 / h);

    #pragma omp atomic
    msum2 += m2;
  }

  return msum1 + msum2;
}

double Foo5(double **array,
            ptrdiff_t w, ptrdiff_t h)
{
  double msum1 = 0;
  double msum2 = 0;

  #pragma omp parallel for reduction(+:msum1, msum2)
  for (ptrdiff_t x = 0; x < w; x++)
  {
    double m1 = 1;
    for (ptrdiff_t y = 0; y != h; ++y)
      m1 *= array[x][y];

    msum1 += m1;
    double m2 = pow(m1, 1.0 / h);
    msum2 += m2;
  }

  return msum1 + msum2;
}

int _tmain(int, _TCHAR*)
{
  const ptrdiff_t W = 100;
  const ptrdiff_t H = 200;
  double **array = CreateArray(W, H);

  const ptrdiff_t TestsCount = 50000;
  Timing t;
  t.StartTiming();
  double result = 0;
  for (ptrdiff_t i = 0; i != TestsCount; ++i)
    result = Foo1(array, W, H);
  t.StopTiming();
  printf("Foo1 - two critical sections\n");
  printf("Foo1 return: %G\n", result);
  printf("Foo1 time = %.3G seconds.\n\n",
    t.GetUserSeconds());

  t.StartTiming();
  for (ptrdiff_t i = 0; i != TestsCount; ++i)
    result = Foo2(array, W, H);
  t.StopTiming();
  printf("Foo2 - one critical sections\n");
  printf("Foo2 return: %G\n", result);
  printf("Foo2 time = %.3G seconds.\n\n",
    t.GetUserSeconds());

  t.StartTiming();
  for (ptrdiff_t i = 0; i != TestsCount; ++i)
    result = Foo3(array, W, H);
  t.StopTiming();
  printf("Foo3 - one critical sections + optimize\n");
  printf("Foo3 return: %G\n", result);
  printf("Foo3 time = %.3G seconds.\n\n",
    t.GetUserSeconds());

  t.StartTiming();
  for (ptrdiff_t i = 0; i != TestsCount; ++i)
    result = Foo4(array, W, H);
  t.StopTiming();
  printf("Foo4 - atomic\n");
  printf("Foo4 return: %G\n", result);
  printf("Foo4 time = %.3G seconds.\n\n",
    t.GetUserSeconds());

  t.StartTiming();
  for (ptrdiff_t i = 0; i != TestsCount; ++i)
    result = Foo5(array, W, H);
  t.StopTiming();
  printf("Foo5 - reduction\n");
  printf("Foo5 return: %G\n", result);
  printf("Foo5 time = %.3G seconds.\n\n",
    t.GetUserSeconds());
  return 0;
}

The program measures the speed of each function. Here are the results we got when compiling the application with Intel(R) C++ Compiler 11.1.071 and launching it on a two-core processor:

Foo1 - two critical sections
Foo1 time = 2.21 seconds.

Foo2 - one critical sections
Foo2 time = 1.66 seconds.

Foo3 - one critical sections + optimize
Foo3 time = 1.48 seconds.

Foo4 - atomic
Foo4 time = 1.69 seconds.

Foo5 - reduction
Foo5 time = 0.863 seconds.

Summary

The results show that the code with two critical sections is the slowest (2.21 seconds). If you unite two critical sections and include the operation of the n-th root calculation into it, the time is reduced to 1.66 seconds. I repeat once again that this operation is rather expensive. If you take it out from the critical section, the speed increases by 1.66 - 1.48 = 0.18 seconds. Thus, we got in practice the evidence of a great speed gain from reducing the number of critical sections.

We also carried out an experiment using more efficient synchronization means. At first we supposed that atomic operations might provide an additional benefit. But in practice the speeds of atomic directive and one critical section almost coincide (the former - 1.69 seconds, the latter - 1.66 seconds). Moreover, if you take the n-th root calculation operation out of the critical section, it turns out that such a function is much more efficient than two atomic directives. The time of executing the function with the optimized critical section is 1.48 seconds while in the case of two atomic operations it is 1.69 seconds.

Reduction directive showed the best result (0.86 seconds).