Log in

Previous Entry | Next Entry

Back in the Heeding History posting in this series, I argued that the solutions put forward to deal with the Great Software Crisis of the 1970s and 1980s could be grouped into the good, the fad, and the ugly. Is a similar grouping appropriate for the present-day Great Multicore Software Crisis?

Perhaps a review of the definition of “good” would be helpful: a good multicore programming language will (1) increase the productivity of existing multicore developers by orders of magnitude, (2) increase the fraction of the population who can make good use of multicore/parallel systems, again by orders of magnitude, or preferably (3) both. Yes, this is a high bar, but this is the bar that must be cleared.

The programming languages in the “ugly” category are quite apparent: MPI, OpenMP, C/C++ with POSIX pthreads or fork/wait, Bourne shell and relatives (don't forget the & operator and the wait command!), and numerous other sturdy indefensibles. Some say that these languages should have been strangled at birth, but on the other hand they are always there when you need them.

It is too early to tell exactly which of the much-hyped multicore programming languages and environments will fall into the “fad” category, but it seems clear that a great many of them will. If you don't like my attitude, feel free to protest all you like. However, I have heard it all long ago from the many and vociferous proponents of such wonderous gems as PASCAL, Modula, Eiffel, ADA, and many others besides. Rest assured that your protestations sound very much like theirs did. And if you really don't like my attitude, the only correct response is to prove me wrong. Just keep the definition of “good” clearly in mind, and also mind the gap between research prototypes and production-quality software.

What if you cannot see that there is a gap between good research and solid practice?

And just what are the good multicore parallel programming languages?


Apr. 1st, 2010 09:54 pm (UTC)
I'm curious what you think about LabVIEW, as one of the touted advantages is that graphical programming is inherently parallel.
Apr. 1st, 2010 10:25 pm (UTC)
Re: LabVIEW?
I have heard of LabVIEW, but cannot claim to know much about it. However, you might be interested in the LabVIEW critique in the Wikipedia entry for LabVIEW.

Just out of curiosity, have you had good success using LabVIEW for creating large complex parallel applications?
May. 8th, 2010 03:07 pm (UTC)
There is one very popular and very successful tool for parallel multiproocessing: 'make -j' !
May. 8th, 2010 03:25 pm (UTC)
Right you are!
And like many other popular and successful tools for parallel processing, specialization is the key to make -j's success. It does one type of job, but does that job very well.