January 2008 - Mpich2-core - mailman3.cels.anl.gov

MPICH2 Threading Overhead
by Pavan Balaji 04 Feb '08

04 Feb '08

Hi all, I've run some experiments for the MPICH2 threading overhead on BG/P and Breadboard (test program is attached). I don't remember if IBM reported that the performance stays constant with increasing threads or if it degrades, but I'm noticing a drop in performance (results below). On BG/P, this is slight yet noticeable, but on breadboard it's drastic. Note that 1 thread refers to "no extra threads" -- the main process does a self send/recv. This is not the fairest comparison since MPICH2-BG/P is based on MPICH2-1.0.4p1, while the breadboard runs are on MPICH2-trunk. I'll try out MPICH2-1.0.4p1 on breadboard as well. But as a longer term solution I'm trying to get MPICH2-BG/P ported to MPICH2-trunk so that I can easily try out any threading enhancements that might go in to trunk from here on. Thanks. -- Pavan ------------------------------------------------------------------------- BG/P: ---- # MPI Message Rate Test with 1 Threads # Size Latency (us) Message Rate (MMPS) 0 1.38 0.725 # MPI Message Rate Test with 2 Threads # Size Latency (us) Message Rate (MMPS) 0 3.59 0.557 # MPI Message Rate Test with 3 Threads # Size Latency (us) Message Rate (MMPS) 0 5.75 0.522 # MPI Message Rate Test with 4 Threads # Size Latency (us) Message Rate (MMPS) 0 7.93 0.504 Breadboard: ---------- # MPI Message Rate Test with 1 Threads # Size Latency (us) Message Rate (MMPS) 0 0.17 5.774 # MPI Message Rate Test with 2 Threads # Size Latency (us) Message Rate (MMPS) 0 1.69 1.180 # MPI Message Rate Test with 3 Threads # Size Latency (us) Message Rate (MMPS) 0 7.54 0.398 # MPI Message Rate Test with 4 Threads # Size Latency (us) Message Rate (MMPS) 0 2.04 1.963 -- Pavan Balaji http://www.mcs.anl.gov/~balaji

4 77

other automated testing
by Dave Goodell 31 Jan '08

31 Jan '08

As I continue to slog through the website migration, I need to know what to do about the various automated testing that is missing from the new website that we previously had. There are several items: * mpich2 test suite: http://www.mcs.anl.gov/research/projects/mpich2/ testing/ * special tests * configure options tests * code coverage analysis * style checker problems * error message extractor problems * non-conforming global symbols * list of FIXMEs Before I go and spend a lot of time making each one of these work, do we still want all of them? My inclination is yes, but if any of them are especially fragile or otherwise useless, it would be nice to know ahead of time. Also, do any of these have planned replacements? -Dave

4 7

Nightly tests
by Pavan Balaji 30 Jan '08

30 Jan '08

http://www.mcs.anl.gov/~balaji/projects/mpich2/nightly/2008-01-30 I think the testing script itself it running fine. Will automate it tonight onward. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

4 3

Nightly tests: 2008-01-26
by Pavan Balaji 28 Jan '08

28 Jan '08

All, Here are the nightly tests on the breadboard machines: http://www.mcs.anl.gov/~balaji/projects/mpich2/nightly/2008-01-26 All runs are only on the 64-bit image. Dave -- all SMPD tests fail with some weird connection refused error. Can you check if the tests are being run properly? Since none of the tests pass, it probably is a problem with the testing script itself. Thanks. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

4 13

Conditional inclusion of AC_CONFIG_SUBDIRS
by Pavan Balaji 28 Jan '08

28 Jan '08

Based on the discussion between some of us on Tuesday, I tried to google for the lack of support for conditional inclusion of AC_CONFIG_SUBDIRS (e.g., if foo; then AC_CONFIG_SUBDIRS(foo); fi). However, everything I found so far seems to indicate that such conditional inclusion is allowed. Did I misunderstand the discussion, or is it something that has been recently fixed by autoconf? If this does work, should we just use the top-level configure to control the lower-level configures? -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

3 8

Connection state machine problem is back
by Pavan Balaji 21 Jan '08

21 Jan '08

I was porting the MPICH2 stack to the IBM PS3 Cell BE system, and found that the connection state machine problem is a lot more apparent on these systems. Most programs (including cpi) fail with this problem even for 16-32 processes. I think it's time to up the priority for this and get it working. Is it worth giving a few more days for the 1.0.7 release to make sure this can run fine? Given the ton of errors that are showing up in the nightly tests right now, this might not be too much of a delay. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

2 1

Nightly Tests
by Pavan Balaji 20 Jan '08

20 Jan '08

2 2

1.0.7rc todo
by Rajeev Thakur 16 Jan '08

16 Jan '08

We plan to have a 1.0.7 release candidate by Monday. * singleton init in smpd (Jayesh) * datatype bug (Darius) * version no. in README and user/install guides * some tests from the Intel test suite seem to be failing. (The other all-red ones are NFS problems, which I am trying to minimize by moving the start times around.) Rajeev

1 0

Re: gasnet / nemesis Patch: statement not reached
by Pavan Balaji 14 Jan '08

14 Jan '08

Brian, CC'ing mpich2-core for their comments. I agree that using MPIDI_Exit is just tricking the compiler, not really solving the problem. But, I don't know which way is a better approach --- to go for the MPIDI_Exit form where we trick the compiler, or use pragmas for *each* "problematic" compiler and thus making the code unnecessarily complicated. Regarding the Segment_manipulate code, this is already the 4th revision that Rob has done, so it's close to the cleanest of what we could get while retaining the performance :-). It's an amazingly complicated function, but has been optimized a ton. I tried breaking it down to smaller functions earlier, but you won't believe how easily we lose performance when I tried to do that. Anyway, I can go either way with the pragma stuff depending on what the rest of the MPICH2 group feels. Thanks. -- Pavan PS: Will fix the simple_pmi.c warning. On 01/14/2008 09:48 AM, Brian Curtis wrote: > Pavan, > > Those changes do obfusticate the use of noreturn functions, thus > tricking the compiler into believing certain lines of code are > reachable. However, this approach will lead to unintended consequences > as it also will trick developers. By adding the MPIDI_Exit function > without the noreturn designation, you have created a facade for the > noreturn exit functions. I understand the intent of the change, but I'd > much prefer the use of #pragma's in this case. Also, the changes added > the following warning: > > "simple_pmi.c", line 353: warning: implicit function declaration: > MPIDI_Exit > > As for segment.c, the "void PREPEND_PREFIX(Segment_manipulate)" function > contains a giant "for(;;)" loop, with no means of exiting the loop with > the exception of returns. We are using the pragma's to prevent the > compiler from warning us about the lines of code that follow this for > loop. Part of the reason this type of code structure pops up is the > size of the function in question--can this be refactored? > > Will you consider reverting these changes and using the pragma's I > provided, instead? > > Regards, > > Brian > > > Pavan Balaji wrote: >> Brian, >> >> Can you try the current version of the trunk and see if this problem >> still exists? >> >>> ./src/mpid/common/datatype/dataloop/segment.c >> >> Btw, I couldn't find the problem in this file (maybe I'm too tired). >> Can you point me to where exactly the error is showing up? >> >> Thanks. >> >> -- Pavan >> > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

3 2

Working from home
by Jayesh Krishna 14 Jan '08

14 Jan '08

Hi, I will be working from home today. I am accessible by email/MSN mesg/phone (571 451 7378). Regards, Jayesh

1 0