Sequential programming is dead. So stop teaching it!

Sequential programming is dead.  So stop teaching it!

This teasing diktat points out an important truth – All major manufactures of CPUs, GPUs and ASICs have moved to a many core design, yet universities and colleges are not training engineers in the parallel and concurrent disciplines needed to efficiently program on such systems. To make matters worse, many of the computer science and engineering faculty are often not yet informed enough to effectively teach the subject, even were it to be offered. The sad fact is that unless a more vigorous program of parallel computing is inserted into the curriculum, most engineering and computer science graduates will not have the skills to provide competitive advantage on multicore and many core platforms.


So start teaching parallelism!

Undergraduates need to be exposed to parallel programming techniques starting in CS1 and then need to build on the skill in every (relevant) course.  This is not the case at most institutions; when they teach parallel computing at all, they often relegate it to advanced topics or elective courses.  That said, there are a number of colleges and universities that have found that it is not all that difficult to incorporate it into their existing curriculum.

Intel Software College course architect Michael Wrinn spoke  with Professor Daniel Ernst ,University of Wisconsin – Eau Claire,   on the topic recently at ITiCSE in Spain where Professor Ernst delivered his paper Concurrent CS: Preparing Students for a Multicore World .  Professor Ernst employs what he calls an integrated approach wherein he mixes concurrency in the already established curriculum.  This lightweight tactic is readily comprehended by the students and does not entail a wholesale rewrite of existing course material.  For an in depth discussion with many examples, view the webinar Daniel led on the subject last month.


Professors Matt Wolfe and Ada Gavrilovska of Georgia Tech will be leading (or have led, depending on when you read this) a webinar on this topic as well Thursday, October 30, 9:00 AM PST.  It is titled Multi-core in Classroom, the view from Georgia Tech.  Register for this webinar and join in the conversation.  The same link will bring up the archive webcast as well.


Ride! Ride, ride!  Wait not for the dawn! Let not the swift wait for the slow!  Ride!

All right, the Nazgul are not coming, but we are facing a sea change in computing. Single core is gone and will not return.  Scaling will be based on our ability to efficiently program for many (and then many many) compute cores.  We have to train the next gen of engineers to think parallel or we will not have done our jobs.  Join in the discussion by attending joining the Intel Academic Community, attending our webinars, contributing to parallel course development on the Academic Community Wiki or even hosting a webinar of your own.  Contact me and I’ll see what we can do.

We are not all mouth, we actually do things

Just a teaser for my next blog entry on our plans for a cross indutry and academia working group on curriculum developement for concurrency and parallelism.  We will be kicking off at Super Computing 08 in Novemeber.  More soon.

For more complete information about compiler optimizations, see our Optimization Notice.


Sequential programming is alive and well. Long live sequential programming!
Another view is that parallel programming needs to be taught on top of sequential programming not instead. I look forward to hearing what the experts have to say at Super Computing 08. See you there.

Sequential programming lives -Le Roi est mort, Vive le Roi. Yet the point remains that parallelism and concurrency must be taught as part of the undergraduate curriculum. Currrently this is not be done enough/comprenhisvly/at all.

Bring Unix back into schools then you may seen the threading trend follow back in..
Intel should do its part by making sure all of its hardware devices work with OpenSolaris, and work well !

That's right - bring OpenSolaris back to academia, and then you'll have a chance at raising awareness of parallel programming. I second that.

(Back when I was at the university taking a course in operating systems, we went through Dijkstra as well as a side by side comparison of Windows NT microkernel and Solaris's own kernel. It did wonders for my understanding of parallel programming. This was almost a decade ago, when most systems were single core.)

Sequential programming is only one type of parallel programming. In sequential programming the flow is maintained by a stack and there is only a single flow. Parallel programming can implement many types of flow-control methodologies. I agree that we should not focus all attention to the single-stack process methodology for beginners.
Our experience in my courses about parallel computing is that students that have a degree in exact science are about 5 times faster to understand the concepts of parallel programming than students that have a degree in computer science. My guess is that computer science graduates are already 'locked' on single task methodologies and their understanding is built of those foundations. Everything new that they learn is first translated in their mind to what they know. In a way it is like teaching manual transmission to someone that is used to automatic transmission (for over 10 years).


I call bull**** (a little on this).

Firstly, (as disclosed) you're a manufacturer of multicore processors and so clearly it's in your interest to be getting people to build software that utilizes the features... especially as it's pretty hard to up sell value much above the current 3ghz cores. Clearly you're a little biased around the benefits of parallelism as it requires cpus that your company enjoys selling.

However, the opportunity of multicore architecture can be looked at in two ways. Yes for certain high end ups, it's more ideal to incorporate parallel threads, but at the same time there is still a lot of be said for the benefits of being able to run multiple sequential programs across different cores to create true multitasking.

I have a 8 core twin Xeon machine sitting under my desk, but I utilize it by operating multiple virtual instances dedicated to various cores within the system. If a given process I wanted to run *forced* me to use parallelism I'd have to dedicate more cores to that given VM and as such either see a reduction of backround resource or have to move this onto dedicated equipment.

So what I'm saying is yes, there is a value in parallelism programming where appropriate, but at the same time I would hate to see a world where every new piece of software (eg my word processor) required a multi-core processor just to run.

Back in the mid 1980's (seems like ancient history), a professor told me one truth about universities -- and I think it certainly applies here. Much of the curriculum universities teach is about 10 years behind the times. New technologies, approaches, and theories change so rapidly (especially in high-tech), that most universities cannot hope to keep up. So they stick with the basics until such time that a new technology becomes main-stream (and business that hire grads are actually looking for those specific skill sets).

Given time, universities will see the light and catch up. We are early movers in this rapidly changing industry. Once businesses and software vendors internalize the benefits of utilizing multiple cores to their maximum potential and begin demanding recent college graduates have those skills, universities will come around.

I'm self taught with most of the stuff I know. I've been out of school for 25 years and things that I learned in school are a bit dated. I think the universities should try to keep up with the times but if the student doesn't take initiative and keep on learning on their own, then in five years it won't matter to that particular person anyway.

Multi threading is a very important subject and it should be understood by all programmers. People who say it's not needed or necessary, don't really understand the power that it provides. If developers understand how to implement multiple threads, they can make a program start in 3 seconds instead of 15. That might not seem like a big deal but use the program 1,000 times and you've saved 12,000 seconds or 200 hours. It's a productivity improvement for businesses.

It's not a difficult subject to understand and implement. But if it's not implemented properly, you can slow down the application by forcing flushes of the processors cache.

DEAD!? as if all on the world is INTEL!? what about cell-phones, embedded devices, Wii-console.
and let me ask you ONE big question: is in it so that parallel programming is nothing more than sequential programming at the same time? to put parallelism against sequential programming is redicilous to begin with. this article is nothing but an intel hype. and ONE more thing. parallelism wasnt even introduced by Intel in main stream. it was NVIDIA & ATI !!!!