Knowing .NET

This is a rather daunting (124 slide) PDF on Sun’s “Fortress” programming language, designed in large part by Guy Steele, which is designed for scientific / mathematical programming. It looks really good — lots of good decisions (take advantage of Unicode, traits and objects, implict and explicit parallelism… well, actually, making parallelism the default for loops is a mistake…).

I do sometimes second-guess myself about whether concurrency is going to be a mainstream concern or whether taking advantage of 90% of your computer’s power (once you get to more than 10 cores) is going to be a niche problem. My gut tells me that mainstream programmers cannot ignore that much of a discrepency in performance; performance is always an issue and, even though the majority of performance problems are not CPU-bound, I just feel that no one will want to say “Yeah, it’s single-threaded” when the pointy-haired boss is looking for someone to blame for performance woes on a 16-core machine.

Found by way of James Governor

 Michael Seuss has a good blog piece on parallelizing code that contains loop-carried dependenciess, which is to say, code such as the following, where the calculation in one pass is dependent on a previous pass’ calculation. The moral of the story, though, is that even when run to the point where the doubles start to overflow (i.e., at the upper limits of the code’s capability), the overhead of creating threads turns out to be an order of magnitude slower than the non-parallel version! (And this in code submitted by boffins on the OpenMP mailing list.)

This is a great example of why neither of the simplistic approaches to parallelization (“everything’s a future” or “let the programmer decide”) will ultimately prevail and how something akin to run-time optimization (a la HotSpot) will have to be used.

PLAIN TEXT

C:

1. const double up = 1.1 ;

2. double Sn=1000.0;

3. double opt[N+1];

4. int n;

5. for (n=0; n<=N; ++n) {

6.   opt[n] = Sn;

7.   Sn *= up;

8. }