As Paul Steinberg mentioned in this previous post (followed up by Kevin Goldsmith, as well as Michael McCool), there will be a panel at IDF tomorrow titled "Parallelism and Education: Navigating through a Sea of Cores". I'll be on that panel and hope to see you there. Also, for interested parties following at home, I believe the panel will be available as a video afterwards. This blog post is a preview of the type of debate we'll be encouraging tomorrow.
I have to agree with Kevin: don't wall-off parallelism as a separate topic. It should appear throughout the curriculum. At the same time I believe it is important that we tame the divergent concepts and terminologies springing from the treatment of parallelism within different application areas (e.g. graphics, compilers, or databases). For example, "stream processing" should have a single meaning for students that applies broadly to pixels in a graphics pipeline as well as event streams in a database.
Personally, I remain hopeful that the next generation will see parallelism not as a series of painful and error-prone modifications to serial code, but as part and parcel of system design and programming -- integrated into their tools and programming languages. My hope rests on an optimistic view of high-level parallel programming abstractions: paradigms like synchronous dataflow and MapReduce data parallelism. Most of these ideas aren't new. That's part of the good news; a lot of the work is done. It is possible already to identify a number of parallel computational models that have a solid theory, long history, and are embodied by increasingly good tools. These are a good place to start to infuse parallelism in curricula.
As long as they learn the concepts, it doesn't matter whether students encounter these parallel abstractions in the form of high level libraries, special features in general purpose languages, or even domain specific languages. Educators can't guess winning technologies, but they can select exemplars to serve as teaching vehicles (Cilk, StreamIT, Hadoop, etc).
I have to agree with Kevin: don't wall-off parallelism as a separate topic. It should appear throughout the curriculum. At the same time I believe it is important that we tame the divergent concepts and terminologies springing from the treatment of parallelism within different application areas (e.g. graphics, compilers, or databases). For example, "stream processing" should have a single meaning for students that applies broadly to pixels in a graphics pipeline as well as event streams in a database.
Personally, I remain hopeful that the next generation will see parallelism not as a series of painful and error-prone modifications to serial code, but as part and parcel of system design and programming -- integrated into their tools and programming languages. My hope rests on an optimistic view of high-level parallel programming abstractions: paradigms like synchronous dataflow and MapReduce data parallelism. Most of these ideas aren't new. That's part of the good news; a lot of the work is done. It is possible already to identify a number of parallel computational models that have a solid theory, long history, and are embodied by increasingly good tools. These are a good place to start to infuse parallelism in curricula.
As long as they learn the concepts, it doesn't matter whether students encounter these parallel abstractions in the form of high level libraries, special features in general purpose languages, or even domain specific languages. Educators can't guess winning technologies, but they can select exemplars to serve as teaching vehicles (Cilk, StreamIT, Hadoop, etc).