By Paul Steinberg (Intel) (4 posts)
on November 12, 2008 at 3:02 pm
Killing the Minotaur - Following Ariadne's thread to Supercomputing08
Well, we're not out of the labyrinth yet, but we are working on it. In preparing for the panel discussion There Is No More Sequential Programming. Why Are We Still Teaching It? at Supercomputing08 , we had each of the participants -AMD, NVidia, IBM, Microsoft, Intel, Sun - submit questions for the panel. Not all responded (insert herding cats cliche here), but many did. Since I did not ask permission, I'll preserve a modicum of anonymity by leaving out the company names. For fun, submit your guesses as to which company proffered which questions ;-)
What do you make of these questions? Are they the right ones? What would you suggest?
Hopefully, we'll see you in Austin or online soon! Learn more here.
Questions
Company A
- What is it that makes serial algorithms the "correct" place to start
teaching software design and development? Much of nature happens in
parallel and humans are well adapted to many parallel tasks.
-
Do we start with serial algorithms because that's what our tools
support? Maybe if we had languages and toolchains that allowed for
the more natural description, expression, development, etc. of
parallel algorithms and data structures then teaching people to do it
wouldn't be any harder than it is currently to teach serial approaches.
-
Do we stick with the serial first (and largely only) approach because
we can't see how we could make such a radical change to the computer
science curriculum, or because it is the pedagogically correct way to
do it?
-
There are many different approaches to and types of parallelism, is
there is a place for most if not all of them at various points
throughout the undergraduate curriculum? We don't talk about
principles of software engineering just in that course, do we?
Algorithms and data structures?
Company B- From the viewpoint of we don't need no steekin' parallelism in our curriculum:
- Sequential programming is a prerequisite to parallel programming, so pretty clear prioritization in favor of sequential programming.
- Most "parallel" programs simply replicate a sequential program (e.g., SETI@HOME) or consist of sequential interface code to parallel relational databases.
- Open-source communities seem quite able to get their members up to speed on parallel programming, so why do we need to add it to the already-packed curriculum?
- Way too many CS grads cannot even really claim to be proficient at sequential programming, so why push parallel??? (http://imranontech.com/2007/01/24/using-fizzbuzz-to-find-developers-who-grok-coding/)
- We do the basics. Even today, parallel programming is in no way basic, or, for that matter, fundamental. Maybe in ten years. Or maybe not.
From the viewpoint of If your curriculum doesn't focus on parallelism, it does not deserve to exist:
- In 1990, the cheapest general-purpose parallel computer cost roughly as much as a house. Now they cost less than a used car. Parallelism is mainstream, and needs to be in any curriculum claiming to be mainstream.
- There are a large number of publicly accessible parallel projects (including the Linux kernel, the Apache web server, several databases, numerous scientific applications...). There is no longer any excuse for failing to cover this increasingly important part of the computer field.
- Given that Moore's Law is no longer driving single-threaded hardware performance, parallelism is absolutely required to meet the industry's performance needs. Given that 1GHz CPUs were available in 2000, if we were seeing the same clock-frequency growth as in the 80s and 90s, we would have 64GHz CPUs next year. Have you seen any announcements of such systems?
- We aren't asking for parallel-programming exotica, just straightforward skills with threads, locks, and message-passing environments. In other words, equip students with practical skills.
- Parallel processors have been commercially available for what? 25 years? Isn't it time that the curriculum covered them?
Company C
Below are my bullets:
- Parallel programming languages are numerous which one should be taught?
- Is graduate level early enough? In the late 1980s it was possible for a 12 year old to sit and write a program that performed "interesting" graphics, today the amount of prior knowledge to do the same thing is large even for a qualified programmer.
- Parallel programming is "hard", should a graduate program, with little time, focus on something that many may fail to grasp?
- If tomorrow's CS graduates fail to adapt to parallel programming what is the implications for an industry dependent on its adoption?
Company D's Devil’s advocate questions
- Sequential programming is a prerequisite to parallel programming, so pretty clear prioritization in favor of sequential programming.
- Most "parallel" programs simply replicate a sequential program (e.g., SETI@HOME) or consist of sequential interface code to parallel relational databases.
- Open-source communities seem quite able to get their members up to speed on parallel programming, so why do we need to add it to the already-packed curriculum?
- Way too many CS grads cannot even really claim to be proficient at sequential programming, so why push parallel??? (http://imranontech.com/2007/01/24/using-fizzbuzz-to-find-developers-who-grok-coding/)
- We do the basics. Even today, parallel programming is in no way basic, or, for that matter, fundamental. Maybe in ten years. Or maybe not.
- Will our graduates need a parallel programming (and stronger architectural)
background to get hired?
Company E
- It is often said that parallel programming is too hard to teach effectively at an undergraduate level, yet there are a growing number of successful implementations of PP into beginning CS curricula. Isn’t our task to get them started on what they will need to develop for future platforms?
- Won’t this problem be taken care of by better tools/compilers/libraries/languages?
- Aren’t we really talking about threaded programming now? Is that really what we want to be teaching? Won't there be better models for parallelism and/or concurrency?
- Should we only be teaching parallel programming?
- Isn’t sequential programming good enough in most cases? Won’t the move to web/cloud based business model negate the need for PP programming to all but a niche segments?
Comments (2)
Trackbacks (0)
Leave a comment
Gordon Wilson
Example :-good code needs well defined decisions= multiple jmp-clauses in the code close together. so two or three tasks execute each branch speculatively any failed taken-up-threads rejoin-the winning thread maybe one instruction beyond the branch to cut down on electricity/cache ,the mechanism could be multiple-read-access to the code execution-scene to the-three-thread-processes.
Whether 2/3/5 are the best to use depends upon the time-to-rejoin parameter and how far beyond a branch we want to regularly catch-up.