April 2011 - Mpich2-core - mailman3.cels.anl.gov

Flat Combining in MPICH2
by Dave Goodell 15 Apr '11

15 Apr '11

I ran across this interesting paper today: http://www.cs.tau.ac.il/research/moran.tzafrir/papers/spaa2010_flat_combini… It discusses "Flat Combining" (FC) as a technique for building scalable concurrent data structures. It has two notable characteristics: 1) Concurrent data structures are built from sequential data structures in a way that is very similar to protecting it with a single mutex. This makes them much easier to implement than a plain lock-free data structure. 2) Such data structures are more scalable (in throughput versus number of threads/processes) than using a normal global lock approach. Reading it made me think of three possibilities that we should investigate at some point: 1) I don't think that we've measured the scalability of the nemesis shared memory queues as the number of communicating processes increases. It's possible that the current swap/CAS-based design may bottleneck on access to the tail of the queue. I don't have a good sense for what the maximal enqueue/dequeue rate would be for a single process sending messages as fast as possible. 2) If item (1) turns out to be a problem, we could investigate an FC-based solution. I'm fairly certain this is doable and would be scalable in throughput vs. processes, but I don't know what the latency impact would be for ping-pong or other microbenchmarks. 3) FC might provide an alternative way to scalably implement multithreaded MPI receive queues, possibly without penalizing the MPI_ANY_SOURCE case as severely as our current designs do. The general concept already shares some similarity with the "channelized recvq" design, but instead it "channelizes" on a per-thread basis. I need to think more about how this all would work, and how it would interact with a channelized DCMF/PAMI, there could be real problems. I also haven't been able to decide whether recvq operations are actually combinable or not, a necessary condition for using FC, IIUC. -Dave

2 1

Nightly tests broken
by Pavan Balaji 13 Apr '11

13 Apr '11

http://www.mcs.anl.gov/research/projects/mpich2/nightly/old -- Pavan Balaji http://www.mcs.anl.gov/~balaji

4 10

1.4
by Rajeev Thakur 07 Apr '11

07 Apr '11

I noticed last night that the nightly tests with Intel compilers on vanquish and octagon were not completing properly (no new output on the web page). The tests were also running the 1.4.x branch. I switched to the 1.4 branch and restarted the tests, but there were still some problems with Intel compilers. I have again started the tests. Let's hold off on releasing 1.4 until we figure out what is happening. I think the tests were fine until Monday. Rajeev

2 6

Serious error in configure fixed in trunk and 1.4.x but not in test version
by William Gropp 06 Apr '11

06 Apr '11

There's a serious typo in configure.in that prevents the coverage tests from running correctly. Its a single character error (a period instead of a comma). As there is a *lot* of uncovered code right now, getting current coverage data is important. This was change #8304, made 3/29/11 . Bill William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

3 2

Intel compiler too slow; license server issue?
by Rajeev Thakur 01 Apr '11

01 Apr '11

The MPICH2 nightly tests with the Intel compilers version 12 (on vanquish and octagon) are taking forever to build. I believe it is a problem with the license server. If I try to compile the simple program attached below with icc a few times, sometimes it compiles instantly, and sometimes it takes a few minutes. Rajeev #include <stdio.h> main() { printf("hello world\n"); }

2 1