Slashdot Mirror

← Back to Stories (view on slashdot.org)

Choice Overload In Parallel Programming

Posted by kdawson on from the too-much-jam dept.

scott3778 writes to recommend a post by Timothy Mattson over at Intel's Research Blog. He argues, convincingly, that the most important paper for programming language designers to read today is one written by two social psychology professors in 2000. This is the well-known academic study, "When Choice is Demotivating: Can One Desire too Much of a Good Thing?" "And then we show them the parallel programming environments they can work with: MPI, OpenMP, Ct, HPF, TBB, Erlang, Shmemm, Portals, ZPL, BSP, CHARM++, Cilk, Co-array Fortran, PVM, Pthreads, windows threads, Tstreams, GA, Java, UPC, Titanium, Parlog, NESL,Split-C... and the list goes on and on. If we aren't careful, the result could very well be a 'choice overload' experience with software vendors running away in frustration."

9 of 288 comments (clear)

  1. link to the paper by skywire · · Score: 5, Informative

    http://www.columbia.edu/~ss957/whenchoice.html

    --
    Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety.
  2. Not really overload... by Anonymous Coward · · Score: 1, Informative

    Ok, there's a lot of different concurrency packages...but there's a lot of different programming languages, too. I could think of at least two dozen, and you probably could too. That make it hard for you to sit down and write code? No? Just like most code gets written in C or Java or any of a small handful of scripting languages, there's a few standout parallel programming packages (pthreads, MPI, Java's built-in). Cilk? Who uses Cilk? If you want to write threaded code in C, you probably use pthreads, because that's what everyone else uses and has experience with. Not much of a choice overload. Unless you're researching concurrency packages, you don't need to know about most of the stuff on that list.

  3. Re:libraries, books, standardization, ... by ljw1004 · · Score: 2, Informative

    F# is an implementation of ocaml on .net, so it benefits from microsoft's fast multithreaded garbage collector. Also you get lots of libraries and documentation for free. I've switched most of my preliminary programming to F#, to be reimplemneted in C# or C++ depending on what's needed. The reimplementation's always between 4 and 10 times as big (in terms of lines of code).

  4. Re:Hmm by n+dot+l · · Score: 2, Informative

    It's useless in cases where you don't have shared memory (though, really, most "general-purpose" solutions are going to be useless in this case).

    It's implementation is, essentialy, compiler magic. This automatically rules it out in a lot of cases where you need precise control of what your code is doing. If, for example, you need logic to spin for a few cycles while a DMA operation completes (so as to not interrupt/stall something else - and yes, people do actually optimize to that level on some platforms) you can't really add that to OMP unless your compiler vendor is willing to make the change for you. With a library based solution you can grab the code and hack your little change into the scheduler without relying on third parties who may or may not be willing to accomodate you.

    That said, it's certianly not useless. I mean, it's damn amazing when it comes to quickly hacking some parallelism into a loop that wasn't really designed with multi-threading in mind.

  5. Re:libraries, books, standardization, ... by Coryoth · · Score: 2, Informative

    Okay, fp!=parallel, but, e.g., one of the big selling points of Erlang is supposed to be that it lends itself to completely transparent use of parallel processors. Mostly what makes Erlang good for parallel programming, however, it is its Actor model, no shared memory, message passing, based approach to concurrency that provides that; the FP side is somewhat incidental (it certainly doesn't hurt, but it isn't required). You can have similarly clean and easy parallelism, as long as you take a message passing style approach, in a non-FP language: take a look at SCOOP for Eiffel which provides fairly transparent parallel code with an OO language.
    --
    Craft Beer Programming T-shirts
  6. Re:It's drivel by Alphax.au · · Score: 2, Informative

    This whole idea of 'choice overload' is so much drivel, IMHO. And, no, I'm not trying to flame here.
    I saw an episode of Catalyst where they interviewed the people who wrote that paper, and gave a demonstration at a supermarket using jars of jam: people threw up their hands and said that there were too many to choose from. The results are definitely not bogus.
  7. Re:Functional programming? Try Python. by GileadGreene · · Score: 2, Informative

    Python ... actually has all of the tools required to do functional programming.
    Much as I like Python (and I do like it), last I checked it doesn't support tail-call optimization, which is pretty much required for many of the recursive algorithms used when doing FP.
  8. Re:Revenge of OO by AHumbleOpinion · · Score: 4, Informative

    Just use pthreads and forget that other nonsense.

    I am not sure you understand the problem, it is *not* how to write a multithreaded program. It is how to write "normal" code, say a for loop, that will automatically be executed in parallel if multiple cores are present.

  9. Apples and Oranges by master_p · · Score: 2, Informative

    Parallel programming has many facets. Libraries like OpenMP can not be compared to Windows threads, for example: the former is a mechanism for doing task/data parallelism at language level, the latter offers the primitives for making threads. PThreads is a thread API similar to win32 threads. I don't see how there is an overload of choices, really.