IDF Concurrency panel follow up -- performance fundamentals matter

By Michael Wrinn (Intel) (12 posts) on August 29, 2008 at 2:37 pm

Our IDF panel (officially, the Academic Community Multi-core Programming Roundable) brought some lively points of view, and at least one recurrent theme. First, the points of view:

Dan Garcia gave a quick overview of the UC Berkeley approach; they really *do* get the new kids coding a version of MapReduce - in the first school term. They do so in the language Scheme, which presents two distinct advantages: it levels the playing field, taking care of the issue of the students' broad range of prior coding experience (no one knows Scheme, apparently), and also, a functional language like Scheme is a very natural way to express MapReduce (4 lines of code, in fact). However -- and I view this as very important -- the curriculum quickly progresses from this academic level through Java and then to C, bringing in the corresponding concurrency model along the way. Students thus, in one school year, see the range of abstractions, right down to levels which expose the underlying architecture, with access to performance details. (Dan's slides are posted: Infusing Concurrency into the Intro CS Undergraduate Curricula).

Tom Murphy reminded us that not all software practitioners arrive from computer science departments; in fact, a great deal of coding goes on in application domains such as physical sciences, biology, engineering, and even social sciences, where performance is a key requirement -- could we please keep them in mind?

Charles Leiserson (from MIT) posted to us that performance motivates parallelism, but performance treatments have been evaporating from CS training over the past decade.

Which brings us to the recurrent theme: performance. The audience, mainly from industry, certainly picked it up; several identified themselves as hiring managers, and lamented the general ignorance of performance and architecture details. At least one of them said he prefers to interview only EE graduates - for software jobs - since CS students typically do not bring what his company needs (the industries represented here were quite varied: search engine, medical instruments, cluster consulting etc).

I wonder if the academic computing universe is splitting into two camps: those where students deal directly with architecture, low-level languages, concurrency, and performance, and those where students stay at a higher level of abstraction (typically expressed with Java or Python)?
And, if that division is true, is that ok with everyone?

Categories: Academic, Parallel Programming

Comments (3)

September 2, 2008 7:32 AM PDT


anon		 So... Why should a physicist, mechanical engineer, etc. need to know about microarchitectures that change every few seconds?

And there are high-performance, high-level languages. No one ever called APL slow. Pretty much all Common Lisp implementations directly compile to hardware. Not only that, they allow modifying the compiler on the fly and support disassembly of compiled code. You can diddle with whatever CPU you have this week to your heart's content. And then throw it out for next week's CPU. The only thing stopping MATLAB(tm)/Octave/R/etc. from incorporating similar compilers is money. No one's willing to pay. Kinda says a lot right there, no?

The vast majority of successful optimizations have been high-level: cache blocking, cache obliviousness (when sensible), and other memory layouts. Similarly, algorithmic changes that avoid communication altogether are far, far faster than any low-level hacks on latency-sensitive algorithms.

I think the complaints can be rephrased. It's far cheaper to get another .001% closer to a brick wall than to tear down the wall.
September 4, 2008 1:11 PM PDT

Richard Altmaier (Intel)
Total Points:
225
Status Points:
175
Green Belt
 Indeed there are practical options to write high level code, and achieve parallelism, such as the MATLAB-like Star-P by Interactive Supercomputing, http://www.interactivesupercomputing.com/

Scientists and engineers need to focus at the algorithmic level. CS students need to build the insides.
September 5, 2008 7:15 AM PDT


Steve Hochschild		 There was also the question some big guy asked about Intel's Java support, or lack thereof. The question was referred to James Reinders, who was in the audience, who gave a quick response that I misinterpreted. Since then, he and I have exchanged emails and we have both clarified our thinking, which is really helpful.

If this session had not been held, we would still be operating under a major misconception, so thanks!

Trackbacks (2)


Leave a comment  

To obtain technical support, please go to Software Support.
Name (required)*

Email (required; will not be displayed on this page)*

Your URL (optional)


Comment*