[dcmf] Fw: MPICH2 threading results

[Michael Blocksome]

Please move this discussion of the dcmf build system to the mailing list.

Thanks!

Michael Blocksome
Blue Gene Messaging Team Lead
Advanced Systems SW Development
blocksom at us.ibm.com

----- Forwarded by Michael Blocksome/Rochester/IBM on 02/06/2008 09:04 AM 
-----

Sameer Kumar/Watson/IBM
02/05/2008 10:52 PM

To
Pavan Balaji <balaji at mcs.anl.gov>
cc
Darius Buntinas <buntinas at mcs.anl.gov>, Dave Goodell 
<goodell at mcs.anl.gov>, Rajeev Thakur <thakur at mcs.anl.gov>, William Gropp 
<wgropp at uiuc.edu>, Ahmad Faraj/Rochester/IBM at IBMUS, Bob 
Cernohous/Rochester/IBM at IBMUS, Brian Smith/Rochester/IBM at IBMUS, 
buntinas at mcs.anl.gov, Craig Stunkel/Watson/IBM at IBMUS, Douglas 
Miller/Rochester/IBM at IBMUS, Gabor Dozsa/Watson/IBM at IBMUS, Jeff 
Parker/Rochester/IBM at IBMUS, Joseph Ratterman/Rochester/IBM at IBMUS, Michael 
Blocksome/Rochester/IBM at IBMUS, Robert Wisniewski/Watson/IBM at IBMUS
Subject
Re: MPICH2 threading results





Hi Pavan,

        Thanks for checking with us.  Here are some comments : 

1)  The top level comm/Make can build both dcmf  (including ccmi the 
collective library)  and MPICH.  May be the configure (at the top level 
and in mpich) scripts can pass options to that Makefile? 
 
        At research we use a slightly differnt way of compiling messaging 
stack.  If you cd to comm/sys/messaging you will find a configure and 
Makefile.in which builds the messaging dir.  You can run configure at the 
comm/sys/messaging (collectives) levels too.  It can also take options 
(--with-rootdir=/.../) to where the bgp/ (arch and runtime dirs) are 
installed.  I just thought I will let you know. 

        The sub-directory sys/ represents a set of system components 
including messaging, collectives, sysdeps (in messaging) etc. The other 
directory libs has higher level programming languages which arent system 
dependent.  The names of the directories predate dcmf and so there are 
also historical.

2)  The arch directory mainly has a set of include files shared between 
the kernel (cnk) and messaging and other components.  In the main 
repository, there is bgp at the top, bgp/arch bgp/cnk, bgp/runtime, 
bgp/comm and others below it.  So it may be a good idea to leave arch in a 
seperate repository and postponing this decision till the kernel is 
open-sourced.

3)  Supporting both options and env vars would be good as different 
researchers/developers may prefer one over the other.

                                                        sameer.





Pavan Balaji <balaji at mcs.anl.gov> 
02/05/2008 04:27 PM

To
Sameer Kumar/Watson/IBM at IBMUS
cc
Darius Buntinas <buntinas at mcs.anl.gov>, Dave Goodell 
<goodell at mcs.anl.gov>, Rajeev Thakur <thakur at mcs.anl.gov>, William Gropp 
<wgropp at uiuc.edu>, Joseph Ratterman/Rochester/IBM at IBMUS
Subject
Re: MPICH2 threading results






Sameer,

> 3)  Git patch for a new configure

Will you be willing to accept a patch to separate out mpich2, dcmf and 
the rest of the code with independent configures? Separating out MPICH2 
alone won't make much of a difference if we have to clone the entire 
repository anyway every time we want to try an alternate version of DCMF.

Here's my thought. You can confirm whether this would be acceptable to 
you guys:

1. Add a separate configure or Makefile in the sys directory which will 
allow us to treat it as a separate and independent package. Btw, just 
out of curiosity, is there a reason this directory is called "sys" 
instead of "dcmf"?

2. Include the arch directory into the sys directory (as suggested by 
Kaz).

3. Add a separate configure for MPICH2 to accept the path to the DCMF 
package we want to use (--with-dcmf=<path_to_dcmf>).

For the third point, there is already an option to pass this information 
in through environment variables. However, changing the environment 
variable does not modify the DCMF path at runtime. That is, the 
environment variables are only used at configure time. So, is this just 
a matter of preference or is there a reason to do this? Either way, we 
can just leave it in there. There's no strong reason to change it.

Thanks.

  -- Pavan

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alcf.anl.gov/pipermail/dcmf/attachments/20080206/eacb767b/attachment.htm>