Multicore Programming Summer School

The University of Illinois at Urbana-Champaign will be conducting a summer school about multicore programming June 22-26, 2009. I spoke with Marc Snir who is organizing the program. Prof. Snir is co-director of UIAC's Universal Parallel Computing Resource Center.

Outside funding for UPCRC beyond internal resources comes entirely from Intel and Microsoft at present.

JW: Professor, what do you mean when you write on your website that you are "a mathematical descendant of Jacques Hadamard"? Are you working on an Anémélectroreculpédalicoupeventombrosoparacloucycle?

MS: No, no ... it is a mere statement of fact. My PHD advisor ... there is a chain of faculty advisors that connects me back to Jacques Hadamard.

JW: UPCRC's White Paper is a pretty good overview of some subset of the issues of parallel computing. What is the academic definition of "multicore programming" in this context?

MS: Our focus is on parallelism for performance using the current architectures and tools.

JW: What's the lineage between this and the parallel algorithms computer science was teaching in the 1980's?

MS: The problem today is how to implement, how to tune the algorithms for the actual hardware. In typical applications you don't need a sophisticated parallel algorithm when you've got eight or 16 cores.

The difficulty today in parallel programming for most multicore platforms is not learning the algorithms one might need. It's that once you have your algorithms, it is still hard to implement them with the current compilers, the debuggers ...

The reason you use muliticore is you need performance. Performance programming itself has not received enough attention in the past decade. We teach algorithms and analysis but the more practical aspects of how you get performance on a given platform is not treated in so detailed a fashion.

JW: What are some typical issues with common toolchains?

MS: In most applications you don't need non-determinism. You want concurrency when executing multiple operations doesn't affect the result. Current parallel programming languages allow non-determinism and thus do not protect you from data races.

We're missing the compiler/language environment equivalent of type safety or memory safety ... we need a language/runtime concept of concurrency safety, of not getting races that are hard to find.

Secondly, the constructs which we use in the languages we are using for parallel programming encourage the writing of non-deterministic programs. We have been using one swiss army knife for parallel programming -- all programs have been using locks, semaphors, and nowadays atomic sections -- but for most parallel applications you want deterministic programming, not mutual exclusion. You do workflow, message queues, parallel loops, etc. instead.

JW: So what does UPCRC do to allieviate these difficulties?

MS: On the practical side we can teach programming practices to use the current tools to write parallel applications. On the research side we can look to how to build parallel langauges that better enforce and support these practices.

JW: What age groups do you anticipate to be in attendance at the summer school?

MS: We pitched it to experienced programmers who are novices to parallel programming. Parallelism used to be for the priests of programming but now everyone has to know about parallelism.

There are two hypotheses: One is that parallel programming is very hard, you have to have a special brain. The second hypothesis is that the tools we have been using are lousy. I'm a strong believer in the second hypothesis.

For more information about the summer school and to apply, visit http://www.upcrc.illinois.edu/summer/2009/. Applications will be accepted online beginning April 15. Applicants will be notified within 3-5 days after submitting applications. The final day to apply is May 15.