PTfS26: Assignment 7: More OpenMP | NHR Learning Platform

Opened: Tuesday, 16 June 2026, 12:00 PM

Due: Wednesday, 24 June 2026, 10:05 AM

(10 crd) OpenMP fun. There is a correctness problem with this OpenMP parallelization. Describe it and fix it.

double x[100], y[100], tmp;
int i;
double work(int);

// initialization code etc. omitted

#pragma omp parallel 
{
  #pragma omp for 
  for(i=0; i<100; i++) {
    tmp=work(i);
    x[i]=x[i]+tmp;
  }
  #pragma omp for
  for(i=1; i<100; i++) {
    y[i]=x[i-1]*y[i];
  }
}

π by the Monte Carlo method. The quarter unit circle in the ﬁrst quadrant with origin at \( (0,0) \) and radius 1 has an area of \( \pi / 4 \). Look at random number pairs in \( [0,1] \times [0,1] \). The probability that such a point lies inside the circle is \( \pi / 4 \), so given enough statistics we are able to calculate \( \pi \) using this so-called “Monte Carlo” method. You can find a code skeleton in monte-carlo.c attached to this assignment.

(a) (20 crd) Write a parallel OpenMP program that performs this task. Use the rand_r() function to get separate random number sequences for all threads (why is this important?). Report the relative error you can achieve with 72 threads and 4 x 10⁹ points (using double precision).

(b) (20 crd) Draw a plot of performance (in iterations per second) vs. number of cores on a Fritz ccNUMA domain (1..18 cores) at constant clock speed (2.4 GHz). Does your performance "scale," i.e., do you get n times faster with n cores instead of one? If you don't: you really should. Fix the problem.
Hint: when the first OpenMP region in a program is entered there may be considerable startup overhead. In order to avoid such effects, execute a "bogus" parallel region before the actual benchmark loop.
Parallel ray tracer. Parallelize a simple ray tracer code using OpenMP. You can ﬁnd the C source raytracer folder attached to this assignment.(If you want to learn more about the theory of a raytracer, we recommend to read the first three chapter of this introduction.)
The picture is divided into so-called tiles (see ﬁgure). The function which is responsible for calculating a tile is called calc_tile(). Important parameters are size (the number of pixels in one direction) and tilesize (the number of pixels of one tile in one direction), both hard-coded at the start of main(). The program prints the picture in PNM format, you can use it to check for correctness and display the image with the geeqie tool that is installed on csnhr.
(a) (20 crd) Parallelize the code with OpenMP and draw a diagram of performance (in Mpixels/s) vs. number of cores on up to 72 physical cores of a Fritz node, using a picture size of 18000x18000 pixels and a tile size of 4500x4500 pixels. When parallelizing the code, make sure that it really computes the image correctly! Set the clock speed to 2.4 GHz. You can set the picture size and the tile size by command line arguments:
```
./raytrace <size> <tilesize>
```
(b) (10 crd) An OpenMP barrier on a full node takes about 10,000 cycles with the Intel compiler but 50,000 cycles with the GCC compiler. Is barrier synchronization a problem in any of the two cases? How can you tell?
(c) (20 crd) Does your code scale up to 72 cores, i.e., does it run 72 times faster than in sequential mode? If it does not, improve the scaling! How did you accomplish this? You have to keep the image size constant at 18000x18000 pixels, but you are free to make any other changes to the code and its parameters. (Hint. Depending on how you did the parallelization, you may want to look up the collapse clause in OpenMP. Also remember that not all pixels are equal.) Document all your settings so that your experiment can be reproduced.

monte-carlo.c
15 June 2026, 5:02 PM
raytracer.zip
15 June 2026, 1:28 PM