I was presented with a challenge the other day. The question was, "What three things do you think must be taught about parallelism in universities, such that, by not teaching these three things professors would be doing a disservice to their students?" A further restriction put on this question was that each topic could only take half an hour or less to cover. Below is a quick description of the lectures that I came up with, in the order of presentation.
Of course there are many more than three things that I would want to put into a university curriculum about parallel programming. If nothing else is ever taught on the topic in a student's academic career, this minimal set prepares for their own explorations of alternate threading models (e.g., Windows Threads, Pthreads, Intel® TBB) or alternates to shared-memory parallel programming (e.g., message-passing, functional languages).
Proposals for adding parallel programming to a Computer Science curriculum frequently gets pushback asking "What do we eliminate from our already over-stuffed curriculum in order to add parallel programming?" The half hour limit is intended to address this concern. I see these three lectures dropping into a first programming class (CS1) that used a language supporting OpenMP, right after loops and loop constructs were discussed. Ninety minutes out of a semester of contact (60 minutes, 3 times a week, for 15 weeks = 2700 minutes) in such a course could be set aside for these topics.
To paraphrase Dennis Miller, "...of course, this is just my opinion. I could be wrong." Does this list cover the minimum set of parallel programming knowledge? Could it be done with only two topics or is there a fourth (or fifth) vital element that I've overlooked? Is shared-memory programming on multi-core processors the way to introduce/practice these topics or would this just scar future programmers? If you were to answer the original question at the top of this post, how would you respond?
Part 1 - Recognizing Parallelism. This lecture points out why parallelism is important in today's software development environments and how to recognize 2 types of opportunities for parallelism (task and data decomposition) within application code. Examples could start with real-world examples of processes that are "executed" in parallel and then provide a programming example.
Part 2 - Shared Memory and Threads. This lecture give more ideas about how the models covered in the previous part are found within serial code, how threads would be used to express that parallelism, and the major concerns programmers need to be aware of when working in shared memory with threads (i.e., data races).
Part 3 - OpenMP Programming.This lecture gives a quick introduction on how to parallelize loops with independent iterations using OpenMP and how OpenMP deals with some of the concerns expressed in the previous lecture. This is intended to give students a chance to actually do some simple parallel programming and see the performance benefits of parallel execution.
Of course there are many more than three things that I would want to put into a university curriculum about parallel programming. If nothing else is ever taught on the topic in a student's academic career, this minimal set prepares for their own explorations of alternate threading models (e.g., Windows Threads, Pthreads, Intel® TBB) or alternates to shared-memory parallel programming (e.g., message-passing, functional languages).
Proposals for adding parallel programming to a Computer Science curriculum frequently gets pushback asking "What do we eliminate from our already over-stuffed curriculum in order to add parallel programming?" The half hour limit is intended to address this concern. I see these three lectures dropping into a first programming class (CS1) that used a language supporting OpenMP, right after loops and loop constructs were discussed. Ninety minutes out of a semester of contact (60 minutes, 3 times a week, for 15 weeks = 2700 minutes) in such a course could be set aside for these topics.
To paraphrase Dennis Miller, "...of course, this is just my opinion. I could be wrong." Does this list cover the minimum set of parallel programming knowledge? Could it be done with only two topics or is there a fourth (or fifth) vital element that I've overlooked? Is shared-memory programming on multi-core processors the way to introduce/practice these topics or would this just scar future programmers? If you were to answer the original question at the top of this post, how would you respond?