OpenMP - Revision history

GethinWilliams: /* A Necessary Aside */

2013-09-05T09:26:48Z

A Necessary Aside

GethinWilliams at 13:48, 17 December 2011

2011-12-17T13:48:24Z

GethinWilliams: /* Cache Coherency & Reductions */

2010-07-30T11:55:51Z

Cache Coherency & Reductions

GethinWilliams: /* Reductions */

2010-07-27T16:06:14Z

Reductions

GethinWilliams: /* Hello, world */

2010-07-20T15:21:22Z

Hello, world

GethinWilliams: /* OpenMP */

2010-07-20T15:21:03Z

OpenMP

GethinWilliams: moved Parallel to OpenMP

2010-07-20T15:19:33Z

moved Parallel to OpenMP

GethinWilliams at 15:19, 20 July 2010

2010-07-20T15:19:05Z

GethinWilliams: /* Introduction */

2010-07-05T16:04:16Z

Introduction

GethinWilliams: /* Introduction */

2010-07-05T16:03:49Z

Introduction

@@ Line 14: / Line 14: @@
 =A Necessary Aside=
-We'll look at some parallel code in a moment--I promise--but before we do we must take a look at some simple serial code and ask ourselves whether we've been as smart as we can and made the code run as fast as it can.  I know you're keen to crack on, but trust me, it's '''really''' important to make sure that your serial code '''optimised''' before converting it into parallel code.  If you don't, any inefficiencies in your code are just going to get magnified as it is run on several processors at the same time, and that's not what you want.
+We'll look at some parallel code in a moment--I promise--but before we do we must take a look at some simple serial code and ask ourselves whether we've been as smart as we can and made the code run as fast as it can.  I know you're keen to crack on, but trust me, it's '''really''' important to make sure that your serial code '''optimised''' before converting it into parallel code.  If you don't, any inefficiencies in your code are just going to get magnified as it is run on several processors at the same time, and that's not what you want.  With that in mind, be sure to look at the course on [http://source.ggy.bris.ac.uk/wiki/Profiling performance analysis] before starting on any parallel programming endeavours.  Indeed, if you are lucky, you may find that your newly optimised code has been sped-up sufficiently and you don't need to do anything else to it!
 =OpenMP=

@@ Line 46: / Line 46: @@
 <pre>
-svn co http://source.ggy.bris.ac.uk/subversion-open/openmp/trunk ./openmp
+svn co https://svn.ggy.bris.ac.uk/subversion-open/openmp/trunk ./openmp
 </pre>

← Older revision		Revision as of 11:55, 30 July 2010
Line 222:		Line 222:

	You can also time, e.g. '''parallel_pi_c.exe'''. Notice how much slower this is than the reduction version. The reason for this is that in the reduction case, each thread updates a private copy of '''sum''' and these private varaibles are combined (using the specified reduction operator) into a single value at the end of the parallel section. In the naive case, each thread is constantly updating a single shared value. A copy of this variable will be kept in cache for each thread and caches for threads running on different processors will need to be kept up-to-date. This is the cache coherency problem and it is a significant issue for shared memory parallelism.		You can also time, e.g. '''parallel_pi_c.exe'''. Notice how much slower this is than the reduction version. The reason for this is that in the reduction case, each thread updates a private copy of '''sum''' and these private varaibles are combined (using the specified reduction operator) into a single value at the end of the parallel section. In the naive case, each thread is constantly updating a single shared value. A copy of this variable will be kept in cache for each thread and caches for threads running on different processors will need to be kept up-to-date. This is the cache coherency problem and it is a significant issue for shared memory parallelism.
		+
		+	==Exercises==
		+
		+	* Write 2 programs using pthreads; one which employs a reduction and one which does not, and use them to highlight the cache coherency problem.

	=Matrix Multiplication=		=Matrix Multiplication=

@@ Line 169: / Line 169: @@
 There are a number of different scheduling keywords we can use.  Try replacing '''static''' with '''dynamic'''.  In this case chunks are handed out to processors as they become available.  You may see a certain (quiet) processor get used several times and so all the processors may not be called upon in the workshare.  Try changing the chunk size too.  Go on, make a mess!  It's the best way to learn:)
-=Reductions=
+=Cache Coherency & Reductions=
 A reduction combines elements from the different threads to form a single result.  This is something that we might like to do quite often.  For example, reductions can be summations or products.  Let's look at the next example:
@@ Line 220: / Line 220: @@
 Note how much quicker the parallel code runs.  You could try changing the number of threads that we utilise (probably up to a maximum of 8, since the hardware most likely has a maximum of 8 processor-cores).  Recompile using '''make''', and re-time the runs.
 =Matrix Multiplication=

@@ Line 54: / Line 54: @@
 <pre>
 cd examples/example1
 </pre>

← Older revision	Revision as of 15:19, 20 July 2010
(No difference)

@@ Line 1: / Line 1: @@
 [[Category:Pragmatic Programming]]
-''''Parallel: Using more than one processor at a time''''
+''''OpenMP: Shared memory parallism''''
 =Introduction=

@@ Line 8: / Line 8: @@
 Sometimes it's handy to have more than one computer.  Let's say that we have a new whizz-bang weather model that takes 26 hours to work out what the weather will do tomorrow.  "Very nice.  Superb accuracy," you say, "but, alas, about as much use as a chocolate teapot."  In order for the model to be useful in the real world, we need it to run faster.  We need to divide up the work it does and run it over two, or more computers.  We need to enter the world of parallel programming.
-"Hippee!" we cry, but a word of caution.  Getting models to work reliably in parallel is a lot--I'll say it again, ''a lot''--harder than getting them to work on a single processor.  Before setting out down the road, it is well worth checking that you really do need your model to run faster, and that you've explored all other avenues to speed up your model before embarking on a parallelisation project.
+"Hippee!" we cry, but a word of caution.  Getting models to work reliably in parallel is a lot--I'll say it again--''a lot'' harder than getting them to work on a single processor.  Before setting out down the road, it is well worth checking that you really do need your model to run faster, and that you've explored all other avenues to speed up your model before embarking on a parallelisation project.
 Still keen?  OK, let's get stuck in.