On Sat, 2011-08-06 at 10:09 -0400, dsimcha wrote: [ . . . ] > Anyhow, D has one key advantage that makes it more tolerant of > communication overhead than most languages: std.parallelism. At least > the way things are set up on the cluster here at Johns Hopkins, each > node has 8 cores. The "traditional" MPI way of doing things is > apparently to allocate 8 MPI processes per node in this case, one per > core. Instead, I'm allocating one process per node, using MPI only for > very coarse grained parallelism and using std.parallelism for more > fine-grained parallelism to keep all 8 cores occupied with one MPI process.
I think increasingly the idiom in the Fortran/C/C++ HPC community is to use MPI on a per address space basis, rather than a per ALU basis, and to use OpenMP to handle the thread control in a given address space handling the multicores. (OpenMP being something totally different to OpenMPI.) In the C++ arena though there is Threading Building Blocks (TBB) which has element of arcane-ness but is a whole lot better than OpenMP. As you point out there are much better, generally higher-level, abstractions that would make HPC code faster as well as much, much easier to maintain. However even with Intel's high budget marketing of some of the alternatives, the HPC community seem steadfast in their support of MPI and OpenMP. Of course they also have codes from the 1970s and 1980s they are in continued use because no-one is prepared to rewrite them. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
