This is beautiful. The omp tool is elegant. The video didactics are excelent. The series made me feel just dumb enough so i would want to learn and just smart enough so i would dare to try new things. Thanks you.
If you want to try the exercise, I've included the uncorrected code for mandel.c below. It is also available on GitHub at github.com/lat/esc/blob/master/exercises/openmp/mandel.c // BEGIN CODE /* ** PROGRAM: Mandelbrot area ** ** PURPOSE: Program to compute the area of a Mandelbrot set. ** Correct answer should be around 1.510659. ** WARNING: this program may contain errors ** ** USAGE: Program runs without input ... just run the executable ** ** HISTORY: Written: (Mark Bull, August 2011). ** Changed "comples" to "d_comples" to avoid collsion with ** math.h complex type (Tim Mattson, September 2011) */ #include #include #include #include # define NPOINTS 1000 # define MAXITER 1000 void testpoint(void); struct d_complex{ double r; double i; }; struct d_complex c; int numoutside = 0; int main(){ int i, j; double area, error, eps = 1.0e-5; // Loop over grid of points in the complex plane which contains the Mandelbrot set, // testing each point to see whether it is inside or outside the set. #pragma omp parallel for default(shared) private(c,eps) for (i=0; i
I think that there is a mistake in the explanation here. The code given at 1.47 cannot do without the barrier after first for loop. This is because the vector C is further used to calculate vector B and hence if all threads do not finish updating C before beginning to calculate B, it could lead to race condition. However the barrier would have made perfect sense if vector B and vector C used vector A as input. Please correct me if I am wrong?
sangeeth, after every pragma omp for loop there is a default barrier. Therefore, you are right in that you need a barrier after the first for loop but wrong in that the barrier is there, it is default behaviour. Only the second loop has no barrier :)
Is it really the case that there is no reason to remove the implicit barrier at the end of a parallelised section of code? What if I wish to run some function multiple times in parallel with different starting conditions, and take the answer from whichever finishes first? For example, factoring a large semiprime I might want to do this.
OpenMP Does "sections" have implicit barrier at the end of its work sharing construct? I guess it does right? (since all work sharing constructs imply barrier)
You are one of the best speakers/teachers I've ever seen.
This is beautiful. The omp tool is elegant. The video didactics are excelent. The series made me feel just dumb enough so i would want to learn and just smart enough so i would dare to try new things. Thanks you.
What an awesome series! Thanks you so much Tim!
If you want to try the exercise, I've included the uncorrected code for mandel.c below. It is also available on GitHub at github.com/lat/esc/blob/master/exercises/openmp/mandel.c
// BEGIN CODE
/*
** PROGRAM: Mandelbrot area
**
** PURPOSE: Program to compute the area of a Mandelbrot set.
** Correct answer should be around 1.510659.
** WARNING: this program may contain errors
**
** USAGE: Program runs without input ... just run the executable
**
** HISTORY: Written: (Mark Bull, August 2011).
** Changed "comples" to "d_comples" to avoid collsion with
** math.h complex type (Tim Mattson, September 2011)
*/
#include
#include
#include
#include
# define NPOINTS 1000
# define MAXITER 1000
void testpoint(void);
struct d_complex{
double r;
double i;
};
struct d_complex c;
int numoutside = 0;
int main(){
int i, j;
double area, error, eps = 1.0e-5;
// Loop over grid of points in the complex plane which contains the Mandelbrot set,
// testing each point to see whether it is inside or outside the set.
#pragma omp parallel for default(shared) private(c,eps)
for (i=0; i
Great Lesson. For the sections construct can we say it creates a one to one mapping relationship with the threads
Wonderful series! Thank you!
7:31There's an advanced OpenMP class? How can I take that?
I think that there is a mistake in the explanation here. The code given at 1.47 cannot do without the barrier after first for loop. This is because the vector C is further used to calculate vector B and hence if all threads do not finish updating C before beginning to calculate B, it could lead to race condition.
However the barrier would have made perfect sense if vector B and vector C used vector A as input.
Please correct me if I am wrong?
sangeeth, after every pragma omp for loop there is a default barrier. Therefore, you are right in that you need a barrier after the first for loop but wrong in that the barrier is there, it is default behaviour. Only the second loop has no barrier :)
You are correct.
@@psebsellars So, the directive `#pragma omp for nowait` affects the for below this directive, not the one above.
holy.... I can use the section to optimize some math calculation stuff..
Matrix multiplication etc.
:D
Is it really the case that there is no reason to remove the implicit barrier at the end of a parallelised section of code? What if I wish to run some function multiple times in parallel with different starting conditions, and take the answer from whichever finishes first? For example, factoring a large semiprime I might want to do this.
Can't you rewrite the code in a way where that's not needed?
@@Ace-gw4uk how would you suggest? Easiest way is just remove barrier.
OpenMP Does "sections" have implicit barrier at the end of its work sharing construct? I guess it does right? (since all work sharing constructs imply barrier)
Yes "sections" have implied barrier, you can use "Nowait" to avoid it