Re: [OMPI devel] [OMPI svn-private] svn:open-mpi r20380
Tim Mattox, Thanks for your very good suggestion; I will make sure that the author of that script incorporates it. It is possible he may not have a history of using Subversion and may not have understood the significance. Since ORNL now has four people working on the BTL move project (cf., "Author: lb7" in the commit message, whereas my username is "koenig") I am not always aware of what some of the other worker bees may have done. Thanks again -- Greg Koenig. On 1/29/09 4:58 PM, "Tim Mattox" wrote: > Greg Koenig, > I would suggest that for this tmp/koenig-btl/modif script > that you use this construct to move files within a > subversion checkout: "svn mv ompi/mca/allocator onet/mca/" > rather than without the "svn". > Using "svn mv" preserves the change history of the files. > > On Wed, Jan 28, 2009 at 1:10 PM, wrote: >> Author: lb7 >> Date: 2009-01-28 13:10:36 EST (Wed, 28 Jan 2009) >> New Revision: 20380 >> URL: https://svn.open-mpi.org/trac/ompi/changeset/20380 >> >> Log: >> modifying script updated >> Text files modified: >> tmp/koenig-btl/modif |17 + >> 1 files changed, 17 insertions(+), 0 deletions(-) >> >> Modified: tmp/koenig-btl/modif >> =>> = >> --- tmp/koenig-btl/modif(original) >> +++ tmp/koenig-btl/modif2009-01-28 13:10:36 EST (Wed, 28 Jan 2009) >> @@ -159,6 +159,14 @@ >> mv ompi/mca/common onet/mca/ >> >> echo >> +echo Moving the allocator there >> +mv ompi/mca/allocator onet/mca/ >> + >> +echo >> +echo Moving the rcache there >> +mv ompi/mca/rcache onet/mca/ >> + > [snip] >
Re: [OMPI devel] RFC: make predefined handles extern to pointers
After some more experiments I found my issue below wasn't due to the definitions but due to how I was compiling my sources. So it turns out that I get the same results from dbx when accessing an MPI_Comm type whether using the original trunk source or using the struct padding. Which makes sense because I did not change the type of MPI_Comm but the actual type of the predefined. Which has no affects on the user variable when the predefined (like MPI_COMM_WORLD) is used as an initializer since in essence we're using the ompi_communicator_t type portion to set the user variable (ie nothing really has changed). So with this latest information, I am going to start coding the other predefines with padding. I'll post the hg workspace before putting back to the trunk. --td Terry Dontje wrote: Per yesterday's concall I did some experiments with the padding changes and looking at MPI_Comm structures in dbx. I believe the concern from George Bosilca was that using the padding changes you wouldn't be able to print out the structures values. What I found with dbx and Sun Studio is that prior to call MPI_Init the ompi_communicator_t forward reference was unresolved so any attempt t print a communicator structure failed because the structure was undefined. However once MPI_Init was called the communicator structure printed out fine and exactly the same as the non-padded implementation. I believe non-padded implementation worked because there was extern struct ompi_communicator_t that was resolved to the library which I imagine pulled in the real structure definition. One could probably force the same for the padded implementation by defining dummy structures that can be externed in mpi.h. To me this seems gross however I wonder does it actually makes sense to print out an MPI communicator before MPI_Init is called? The values of the field should be either 0 or garbage. So I am really curious if the above is a problem anyways. --td Terry Dontje wrote: Another update for this RFC. It turns out that using pointers instead of structures as initializers would prevent someone from initializing a global to one of the predefined handles. So instead, we decided to go the route of padding the structures to provide us with the ability to not overrun the bss section. I would like to discuss any objections to this solution on tomorrow's OMPI concall. thanks, --td Terry Dontje wrote: Just wanted to give an update. On a workspace with just the predefined communicators converted to opaque pointers I've ran netpipe and hpcc performance tests and compared the results before and after the changes. The differences in performance with 10 sample run was undetectable. I've also tested using comm_world that I can have an a.out compile and link with a non-debug version of the library and then run the a.out successfully with a debug version of the library. At a simple level this proves that the change actually does what we believe it should. I will be completing the rest of handles in the next couple days. Upon completion I will rerun the same tests above and test running hpcc with a debug and non-debug version of the library without recompiling. I believe I am on track to putting this back to the trunk by the end of next week. So if anyone has any issues with this please speak up. thanks, --td Graham, Richard L. wrote: No specific test, just an idea how this might impact an app. I am guessing it won't even be noticable. Rich - Original Message - From: devel-boun...@open-mpi.org To: Open MPI Developers Sent: Thu Dec 18 07:13:08 2008 Subject: Re: [OMPI devel] RFC: make predefined handles extern to pointers Richard Graham wrote: Terry, Is there any way you can quantify the cost ? This seems reasonable, but would be nice to get an idea what the performance cost is (and not within a tight loop where everything stays in cache). Rich Ok, I guess that would eliminate any of the simple perf tests like IMB, netperf, and such. So do you have something else in mind, maybe HPCC? --td On 12/16/08 10:41 AM, "Terry D. Dontje" wrote: WHAT: To make predefined handles extern to pointers instead of an address of an extern to a structure. WHY: To make OMPI more backwards compatible in regards to changes to structures that define predefined handles. WHERE: In the trunk. ompi/include/mpi.h.in and places in ompi that directly use the predefined handles. WHEN: 01/24/2009 TIMEOUT: 01/10/2009 The point of this change is to improve the odds that an MPI application does not have to recompile when changes are made to the OMPI library. In this case specifically the predefined handles that use the structures for communicators, groups, ops, datatypes, error handlers, win, file, and info. An example of the changes for the communicator predefined handles can be found in the hg tmp workspace at ssh:/
[OMPI devel] Change of API in mpool
Send yet again...
RFC: Change of API in mpool
WHAT: Remove dependency on ompi_info_t in mca_mpool_base_alloc
WHY: To be able to move mpool out of the ompi-layer.
WHERE: Changes just in the mpool and in ompi/mpi/c/alloc_mem.c
WHEN: Open MPI-1.4
TIMEOUT: February 3, 2009.
-
Details:
WHY:
With the proposed move of the BTL framework out of the ompi-layer, we
need to move/copy a few dependant class- and other functionality with it
(omp_free_list, ompi_bitmap, ompi_rb_tree, common, mpool, allocator,
rcache).
The only real dependency problem, visible right now, that requires a
change is the function mca_mpool_base_alloc, which requires ompi_info_t.
WHAT:
In order to make mca_mpool_base_alloc oblivious of MPI, we'd propose
passing all relevant info as opal_list_t -- and prepare this by the only
caller ompi/mpi/c/alloc_mem.c, which only copies ("mpool",value)-pairs
into a list (if there are any).
The patchlet can be applied to trunk / or the branch koenig-btl, however,
I left out the required (but boring) svn mv and rename of ompi->onet.
Has been tested with the supplied test-program, produces the expected
results.
Any comments are welcome.
CU,
Rainer
--
Rainer Keller, PhD Tel: (865) 241-6293
Oak Ridge National Lab Fax: (865) 241-4811
PO Box 2008 MS 6164 Email: kel...@ornl.gov
Oak Ridge, TN 37831-2008AIM/Skype: rusraink
Index: onet/mca/mpool/mpool.h
===
--- onet/mca/mpool/mpool.h (revision 20371)
+++ onet/mca/mpool/mpool.h (working copy)
@@ -51,6 +51,20 @@
OMPI_DECLSPEC OBJ_CLASS_DECLARATION(mca_mpool_base_registration_t);
/**
+ * \internal
+ * Used to pass Info from the ompi-layer down.
+ */
+struct mca_mpool_base_info_entry_t {
+opal_list_item_t super;
+char * value;
+};
+
+typedef struct mca_mpool_base_info_entry_t mca_mpool_base_info_entry_t;
+
+OMPI_DECLSPEC OBJ_CLASS_DECLARATION(mca_mpool_base_info_entry_t);
+
+
+/**
* component initialize
*/
typedef struct mca_mpool_base_module_t* (*mca_mpool_base_component_init_fn_t)(
@@ -208,7 +222,7 @@
* @retval pointer to the allocated memory
* @retval NULL on failure
*/
-OMPI_DECLSPEC void * mca_mpool_base_alloc(size_t size, struct ompi_info_t * info);
+OMPI_DECLSPEC void * mca_mpool_base_alloc(size_t size, opal_list_t *info_list);
/**
* Function to free memory previously allocated by mca_mpool_base_alloc
Index: onet/mca/mpool/base/mpool_base_alloc.c
===
--- onet/mca/mpool/base/mpool_base_alloc.c (revision 20371)
+++ onet/mca/mpool/base/mpool_base_alloc.c (working copy)
@@ -23,13 +23,36 @@
#if HAVE_STRING_H
#include
#endif /* HAVE_STRING_H */
-#include "ompi/mca/mpool/mpool.h"
+#include "opal/threads/mutex.h"
+#include "onet/mca/mpool/mpool.h"
#include "base.h"
#include "mpool_base_tree.h"
-#include "opal/threads/mutex.h"
#include "mpool_base_mem_cb.h"
/**
+ * Pass information from the ompi-layer to the mpool
+ */
+static void mca_mpool_base_info_constructor(mca_mpool_base_info_entry_t * entry);
+static void mca_mpool_base_info_destructor(mca_mpool_base_info_entry_t *entry);
+
+OBJ_CLASS_INSTANCE(mca_mpool_base_info_entry_t,
+ opal_list_item_t,
+ mca_mpool_base_info_constructor,
+ mca_mpool_base_info_destructor);
+
+static void mca_mpool_base_info_constructor(mca_mpool_base_info_entry_t * entry)
+{
+}
+
+static void mca_mpool_base_info_destructor(mca_mpool_base_info_entry_t *entry)
+{
+if (NULL != entry->value) {
+free (entry->value);
+}
+}
+
+
+/**
* Memory Pool Registration
*/
@@ -93,7 +116,7 @@
* @retval pointer to the allocated memory
* @retval NULL on failure
*/
-void *mca_mpool_base_alloc(size_t size, ompi_info_t *info)
+void *mca_mpool_base_alloc(size_t size, opal_list_t *info_list)
{
opal_list_item_t * item;
int num_modules = opal_list_get_size(&mca_mpool_base_modules);
@@ -107,8 +130,9 @@
mca_mpool_base_module_t *mpool;
void * mem = NULL;
int flag = 0;
-bool match_found = false;
+bool mpool_matched = false;
bool mpool_requested = false;
+int info_list_size;
if(num_modules > 0) {
has_reg_function = (mca_mpool_base_selected_module_t **)
@@ -125,7 +149,9 @@
mpool_tree_item->num_bytes = size;
mpool_tree_item->count = 0;
-if(&ompi_mpi_info_null == info)
+info_list_size = opal_list_get_size (info_list);
+
+if(0 == info_list_size)
{
for(item = opal_list_get_first(&mca_mpool_base_modules);
item != opal_list_get_end(&mca_mpool_base_modules);
@@ -143,33 +169,24 @@
}
else
{
-int num_keys;
-char key[MPI_MAX_INFO_KEY + 1];
-char value[MPI_MAX_INFO_VAL + 1];
+mca_mpool_base_info_entry_t * info_list_item
[OMPI devel] RFC: Move of ompi_bitmap_t
On behalf of Laurent Broto RFC: Move of ompi_bitmap_t WHAT: Move ompi_bitmap_t into opal or onet-layer WHY: Remove dependency on ompi-layer. WHERE: ompi/class WHEN: Open MPI-1.4 TIMEOUT: February 3, 2009. - Details: WHY: The ompi_bitmap_t is being used in various places within opal/orte/ompi. With the proposed splitting of BTLs into a separate library, we are currently investigating several of the differences between ompi/class/* and opal/class/* One of the items is the ompi_bitmap_t which is quite similar to the opal_bitmap_t. The question is, whether we can remove favoring a solution just in opal. WHAT: The data structures in the opal-version are the same, so is the interface, the implementation is *almost* the same The difference is the Fortran handles ;-]! Maybe we're missing something but could we have a discussion, on why Fortran sizes are playing a role here, and if this is a hard requirement, how we could settle that into that current interface (possibly without a notion of Fortran, but rather, set some upper limit that the bitmap may grow to?) With best regards, Laurent and Rainer -- Rainer Keller, PhD Tel: (865) 241-6293 Oak Ridge National Lab Fax: (865) 241-4811 PO Box 2008 MS 6164 Email: kel...@ornl.gov Oak Ridge, TN 37831-2008AIM/Skype: rusraink
Re: [OMPI devel] RFC: Move of ompi_bitmap_t
So once again, I bring up my objection of this entire line of moving until such time as the entire process is properly mapped out. I believe it's premature to being moving around code in preparation for a move that hasn't been proven viable yet. Until there is concrete evidence that such a move is possible, won't degrade application performance, and does not make the code totally unmaintainable, I believe that any related code changes should not be brought into the trunk. Brian On Jan 30, 2009, at 12:30 PM, Rainer Keller wrote: On behalf of Laurent Broto RFC: Move of ompi_bitmap_t WHAT: Move ompi_bitmap_t into opal or onet-layer WHY: Remove dependency on ompi-layer. WHERE: ompi/class WHEN: Open MPI-1.4 TIMEOUT: February 3, 2009. - Details: WHY: The ompi_bitmap_t is being used in various places within opal/orte/ ompi. With the proposed splitting of BTLs into a separate library, we are currently investigating several of the differences between ompi/class/* and opal/class/* One of the items is the ompi_bitmap_t which is quite similar to the opal_bitmap_t. The question is, whether we can remove favoring a solution just in opal. WHAT: The data structures in the opal-version are the same, so is the interface, the implementation is *almost* the same The difference is the Fortran handles ;-]! Maybe we're missing something but could we have a discussion, on why Fortran sizes are playing a role here, and if this is a hard requirement, how we could settle that into that current interface (possibly without a notion of Fortran, but rather, set some upper limit that the bitmap may grow to?) With best regards, Laurent and Rainer -- Rainer Keller, PhD Tel: (865) 241-6293 Oak Ridge National Lab Fax: (865) 241-4811 PO Box 2008 MS 6164 Email: kel...@ornl.gov Oak Ridge, TN 37831-2008AIM/Skype: rusraink ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Brian Barrett Open MPI developer http://www.open-mpi.org/
Re: [OMPI devel] RFC: Move of ompi_bitmap_t
I second Brian's concern. So unless this is just an announcement that this is being done on a tmp branch only until everything is in order I think we need further discussions. --td Brian Barrett wrote: So once again, I bring up my objection of this entire line of moving until such time as the entire process is properly mapped out. I believe it's premature to being moving around code in preparation for a move that hasn't been proven viable yet. Until there is concrete evidence that such a move is possible, won't degrade application performance, and does not make the code totally unmaintainable, I believe that any related code changes should not be brought into the trunk. Brian On Jan 30, 2009, at 12:30 PM, Rainer Keller wrote: On behalf of Laurent Broto RFC: Move of ompi_bitmap_t WHAT: Move ompi_bitmap_t into opal or onet-layer WHY: Remove dependency on ompi-layer. WHERE: ompi/class WHEN: Open MPI-1.4 TIMEOUT: February 3, 2009. - Details: WHY: The ompi_bitmap_t is being used in various places within opal/orte/ompi. With the proposed splitting of BTLs into a separate library, we are currently investigating several of the differences between ompi/class/* and opal/class/* One of the items is the ompi_bitmap_t which is quite similar to the opal_bitmap_t. The question is, whether we can remove favoring a solution just in opal. WHAT: The data structures in the opal-version are the same, so is the interface, the implementation is *almost* the same The difference is the Fortran handles ;-]! Maybe we're missing something but could we have a discussion, on why Fortran sizes are playing a role here, and if this is a hard requirement, how we could settle that into that current interface (possibly without a notion of Fortran, but rather, set some upper limit that the bitmap may grow to?) With best regards, Laurent and Rainer -- Rainer Keller, PhD Tel: (865) 241-6293 Oak Ridge National Lab Fax: (865) 241-4811 PO Box 2008 MS 6164 Email: kel...@ornl.gov Oak Ridge, TN 37831-2008AIM/Skype: rusraink ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] Change of API in mpool
I think this fits into the same category of objections as to the other
RFC - it should be done in the tmp branch and held there until the
entire concept is validated.
In this case, my concern would focus solely on the question of
conversion time. Somewhere up the chain, somebody is passing an
ompi_info_t that eventually hits this level. At what level would we
have to convert that to an opal_list_t, and what timing would be
impacted by that conversion?
Minus that understanding, there really is no way to judge the
potential impact of this proposed change.
Ralph
On Jan 30, 2009, at 12:29 PM, Rainer Keller wrote:
Send yet again...
RFC: Change of API in mpool
WHAT: Remove dependency on ompi_info_t in mca_mpool_base_alloc
WHY: To be able to move mpool out of the ompi-layer.
WHERE: Changes just in the mpool and in ompi/mpi/c/alloc_mem.c
WHEN: Open MPI-1.4
TIMEOUT: February 3, 2009.
-
Details:
WHY:
With the proposed move of the BTL framework out of the ompi-layer, we
need to move/copy a few dependant class- and other functionality
with it
(omp_free_list, ompi_bitmap, ompi_rb_tree, common, mpool, allocator,
rcache).
The only real dependency problem, visible right now, that requires a
change is the function mca_mpool_base_alloc, which requires
ompi_info_t.
WHAT:
In order to make mca_mpool_base_alloc oblivious of MPI, we'd propose
passing all relevant info as opal_list_t -- and prepare this by the
only
caller ompi/mpi/c/alloc_mem.c, which only copies ("mpool",value)-pairs
into a list (if there are any).
The patchlet can be applied to trunk / or the branch koenig-btl,
however,
I left out the required (but boring) svn mv and rename of ompi->onet.
Has been tested with the supplied test-program, produces the expected
results.
Any comments are welcome.
CU,
Rainer
--
Rainer Keller, PhD Tel: (865) 241-6293
Oak Ridge National Lab Fax: (865) 241-4811
PO Box 2008 MS 6164 Email: kel...@ornl.gov
Oak Ridge, TN 37831-2008AIM/Skype: rusraink
<
mpool_patchlet
-2009.01.29
.diff>___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] RFC: Move of ompi_bitmap_t
This should really be viewed as a code maintenance RFC. The reason this came up in the first place is because we are investigating the btl move, but these are really two very distinct issues. There are two bits of code that have virtually the same functionality - they do have the same interface I am told. The question is, is there a good reason to keep two different versions in the repository ? Not knowing the history of why a second version was created this is an inquiry. Is there some performance advantage, or some other advantage to having these two versions ? Rich On 1/30/09 3:23 PM, "Terry D. Dontje" wrote: > I second Brian's concern. So unless this is just an announcement that > this is being done on a tmp branch only until everything is in order I > think we need further discussions. > > --td > > Brian Barrett wrote: >> So once again, I bring up my objection of this entire line of moving >> until such time as the entire process is properly mapped out. I >> believe it's premature to being moving around code in preparation for >> a move that hasn't been proven viable yet. Until there is concrete >> evidence that such a move is possible, won't degrade application >> performance, and does not make the code totally unmaintainable, I >> believe that any related code changes should not be brought into the >> trunk. >> >> Brian >> >> >> On Jan 30, 2009, at 12:30 PM, Rainer Keller wrote: >> >>> On behalf of Laurent Broto >>> >>> RFC: Move of ompi_bitmap_t >>> >>> WHAT: Move ompi_bitmap_t into opal or onet-layer >>> >>> WHY: Remove dependency on ompi-layer. >>> >>> WHERE: ompi/class >>> >>> WHEN: Open MPI-1.4 >>> >>> TIMEOUT: February 3, 2009. >>> >>> - >>> Details: >>> WHY: >>> The ompi_bitmap_t is being used in various places within >>> opal/orte/ompi. With >>> the proposed splitting of BTLs into a separate library, we are currently >>> investigating several of the differences between ompi/class/* and >>> opal/class/* >>> >>> One of the items is the ompi_bitmap_t which is quite similar to the >>> opal_bitmap_t. >>> The question is, whether we can remove favoring a solution just in opal. >>> >>> WHAT: >>> The data structures in the opal-version are the same, >>> so is the interface, >>> the implementation is *almost* the same >>> >>> The difference is the Fortran handles ;-]! >>> >>> Maybe we're missing something but could we have a discussion, on why >>> Fortran >>> sizes are playing a role here, and if this is a hard requirement, how >>> we could >>> settle that into that current interface (possibly without a notion of >>> Fortran, >>> but rather, set some upper limit that the bitmap may grow to?) >>> >>> With best regards, >>> Laurent and Rainer >>> -- >>> >>> Rainer Keller, PhD Tel: (865) 241-6293 >>> Oak Ridge National Lab Fax: (865) 241-4811 >>> PO Box 2008 MS 6164 Email: kel...@ornl.gov >>> Oak Ridge, TN 37831-2008AIM/Skype: rusraink >>> >>> >>> >>> >>> >>> >>> ___ >>> devel mailing list >>> de...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> >> > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] RFC: Move of ompi_bitmap_t
The history is simple. Originally, there was one bitmap_t in orte that was also used in ompi. Then the folks working on Fortran found that they had to put a limit in the bitmap code to avoid getting values outside of Fortran's range. However, this introduced a problem - if we had the limit in the orte version, then we limited ourselves unnecessarily, and introduced some abstraction questions since orte knows nothing about Fortran. So two were created. Then the orte_bitmap_t was blown away at a later time when we removed the GPR as George felt it wasn't necessary (which was true). It was later reborn when we needed it in the routed system, but this time it was done in opal as others indicated a potential more general use for that capability. The problem with uniting the two is that you either have to introduce Fortran-based limits into opal (which messes up the non-ompi uses), or deal with the Fortran limits in some other fashion. Neither is particularly pleasant, though it could be done. I think it primarily is a question for the Fortran folks to address - can they deal with Fortran limits in some other manner without making the code unmanageable and/or taking a performance hit? Ralph On Jan 30, 2009, at 2:40 PM, Richard Graham wrote: This should really be viewed as a code maintenance RFC. The reason this came up in the first place is because we are investigating the btl move, but these are really two very distinct issues. There are two bits of code that have virtually the same functionality - they do have the same interface I am told. The question is, is there a good reason to keep two different versions in the repository ? Not knowing the history of why a second version was created this is an inquiry. Is there some performance advantage, or some other advantage to having these two versions ? Rich On 1/30/09 3:23 PM, "Terry D. Dontje" wrote: I second Brian's concern. So unless this is just an announcement that this is being done on a tmp branch only until everything is in order I think we need further discussions. --td Brian Barrett wrote: So once again, I bring up my objection of this entire line of moving until such time as the entire process is properly mapped out. I believe it's premature to being moving around code in preparation for a move that hasn't been proven viable yet. Until there is concrete evidence that such a move is possible, won't degrade application performance, and does not make the code totally unmaintainable, I believe that any related code changes should not be brought into the trunk. Brian On Jan 30, 2009, at 12:30 PM, Rainer Keller wrote: On behalf of Laurent Broto RFC: Move of ompi_bitmap_t WHAT: Move ompi_bitmap_t into opal or onet-layer WHY: Remove dependency on ompi-layer. WHERE: ompi/class WHEN: Open MPI-1.4 TIMEOUT: February 3, 2009. - Details: WHY: The ompi_bitmap_t is being used in various places within opal/orte/ompi. With the proposed splitting of BTLs into a separate library, we are currently investigating several of the differences between ompi/class/* and opal/class/* One of the items is the ompi_bitmap_t which is quite similar to the opal_bitmap_t. The question is, whether we can remove favoring a solution just in opal. WHAT: The data structures in the opal-version are the same, so is the interface, the implementation is *almost* the same The difference is the Fortran handles ;-]! Maybe we're missing something but could we have a discussion, on why Fortran sizes are playing a role here, and if this is a hard requirement, how we could settle that into that current interface (possibly without a notion of Fortran, but rather, set some upper limit that the bitmap may grow to?) With best regards, Laurent and Rainer -- Rainer Keller, PhD Tel: (865) 241-6293 Oak Ridge National Lab Fax: (865) 241-4811 PO Box 2008 MS 6164 Email: kel...@ornl.gov Oak Ridge, TN 37831-2008AIM/Skype: rusraink ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] RFC: Move of ompi_bitmap_t
Thanks - very helpful. Rich On 1/30/09 4:59 PM, "Ralph Castain" wrote: > The history is simple. Originally, there was one bitmap_t in orte that > was also used in ompi. Then the folks working on Fortran found that > they had to put a limit in the bitmap code to avoid getting values > outside of Fortran's range. However, this introduced a problem - if we > had the limit in the orte version, then we limited ourselves > unnecessarily, and introduced some abstraction questions since orte > knows nothing about Fortran. > > So two were created. Then the orte_bitmap_t was blown away at a later > time when we removed the GPR as George felt it wasn't necessary (which > was true). It was later reborn when we needed it in the routed system, > but this time it was done in opal as others indicated a potential more > general use for that capability. > > The problem with uniting the two is that you either have to introduce > Fortran-based limits into opal (which messes up the non-ompi uses), or > deal with the Fortran limits in some other fashion. Neither is > particularly pleasant, though it could be done. > > I think it primarily is a question for the Fortran folks to address - > can they deal with Fortran limits in some other manner without making > the code unmanageable and/or taking a performance hit? > > Ralph > > > On Jan 30, 2009, at 2:40 PM, Richard Graham wrote: > >> This should really be viewed as a code maintenance RFC. The reason >> this >> came up in the first place is because we are investigating the btl >> move, but >> these are really two very distinct issues. There are two bits of >> code that >> have virtually the same functionality - they do have the same >> interface I am >> told. The question is, is there a good reason to keep two different >> versions in the repository ? Not knowing the history of why a second >> version was created this is an inquiry. Is there some performance >> advantage, or some other advantage to having these two versions ? >> >> Rich >> >> >> On 1/30/09 3:23 PM, "Terry D. Dontje" wrote: >> >>> I second Brian's concern. So unless this is just an announcement >>> that >>> this is being done on a tmp branch only until everything is in >>> order I >>> think we need further discussions. >>> >>> --td >>> >>> Brian Barrett wrote: So once again, I bring up my objection of this entire line of moving until such time as the entire process is properly mapped out. I believe it's premature to being moving around code in preparation for a move that hasn't been proven viable yet. Until there is concrete evidence that such a move is possible, won't degrade application performance, and does not make the code totally unmaintainable, I believe that any related code changes should not be brought into the trunk. Brian On Jan 30, 2009, at 12:30 PM, Rainer Keller wrote: > On behalf of Laurent Broto > > RFC: Move of ompi_bitmap_t > > WHAT: Move ompi_bitmap_t into opal or onet-layer > > WHY: Remove dependency on ompi-layer. > > WHERE: ompi/class > > WHEN: Open MPI-1.4 > > TIMEOUT: February 3, 2009. > > - > Details: > WHY: > The ompi_bitmap_t is being used in various places within > opal/orte/ompi. With > the proposed splitting of BTLs into a separate library, we are > currently > investigating several of the differences between ompi/class/* and > opal/class/* > > One of the items is the ompi_bitmap_t which is quite similar to the > opal_bitmap_t. > The question is, whether we can remove favoring a solution just > in opal. > > WHAT: > The data structures in the opal-version are the same, > so is the interface, > the implementation is *almost* the same > > The difference is the Fortran handles ;-]! > > Maybe we're missing something but could we have a discussion, on > why > Fortran > sizes are playing a role here, and if this is a hard requirement, > how > we could > settle that into that current interface (possibly without a > notion of > Fortran, > but rather, set some upper limit that the bitmap may grow to?) > > With best regards, > Laurent and Rainer > -- > > Rainer Keller, PhD Tel: (865) 241-6293 > Oak Ridge National Lab Fax: (865) 241-4811 > PO Box 2008 MS 6164 Email: kel...@ornl.gov > Oak Ridge, TN 37831-2008AIM/Skype: rusraink > > > > > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > >>> >>> ___ >>> devel mailing
