3 ms·

I'm not optimistic about the kinds of approaches mentioned fostering "ubiquitous parallelism." Just as a better compiler, language, or implementation technique

I'm not optimistic about the kinds of approaches mentioned fostering "ubiquitous parallelism." Just as a better compiler, language, or implementation technique won't make a bubble-sort into a quicksort, I don't expect them to turn essentially sequential programs into parallel ones. We need new kinds of algorithms, not better programming techniques. Being explicit and telling the compiler all about isolated pockets of dependencies does not ultimately defeat their constraints on the overall program. I remember a statement by Knuth in an interview[1]: "Let me put it this way: During the past 50 years, I’ve written well over a thousand programs, many of which have substantial size. I can’t think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading." [1]: http://www.informit.com/articles/article.aspx?p=1193856 http://www.informit.com/articles/article.aspx?p=1193856

jerf 10y ago
A lot has happened in that space since that 2008 blog post. Unfortunately for us all, what has happened is that automatic parallelism has basically been disproved. It effectively isn't possible. At best, it requires a language so profoundly different than anything we have to prod developers into using it in a way that can be automatically parallelized that it's arguably not really automatic anymore, but a new restricted DSL for the task. Similarly for STM; it's only practical in a language with enough mutation control built into it that nobody will want to use it, i.e., Haskell. It can't be added to conventional languages. IIRC it was already looking pretty grim by 2008, but now it's certain; you can't bodge STM onto a conventional imperative language.