Re: [OMPI devel] RFC: make predefined handles extern to pointers
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://www.open-mpi.org/~tdd/hg/predefcompat. Note, the one downfall that Jeff and I could think of by doing this is you potentially add one level of indirection but I believe that will be a small overhead and if you use one of the predefined handles repetitively (like in a loop) that the address will probably be stored in a register once and no additional over should be seen due to this change. ___ 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/listi
Re: [OMPI devel] BTL/sm meeting on Wed after Forum
Any chance of a conference call, this is very interesting issue , but we can't attend in person :( On Tue, Jan 27, 2009 at 10:38 PM, Jeff Squyres wrote: > On Jan 27, 2009, at 3:37 PM, Eugene Loh wrote: > >>> Jeff Squyres >>> Rich Graham >>> Brian Barrett >>> George Bosilca >>> Thomas Herault >>> Terry Dontje >> >> Is this Feb 11? How would it be if I attended? > > I'm a bozo -- I forgot to list you (even though Terry and I explicitly > discussed this); sorry! Yes, it would be great if you attended. > > -- > Jeff Squyres > Cisco Systems > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
Re: [OMPI devel] BTL/sm meeting on Wed after Forum
Sure, we cam do that. .ajor problem will be the timezone diff... -jms Sent from my PDA. No type good. -Original Message- From: Lenny Verkhovsky [mailto:lenny.verkhov...@gmail.com] Sent: Wednesday, January 28, 2009 10:56 AM Eastern Standard Time To: Open MPI Developers Subject:Re: [OMPI devel] BTL/sm meeting on Wed after Forum Any chance of a conference call, this is very interesting issue , but we can't attend in person :( On Tue, Jan 27, 2009 at 10:38 PM, Jeff Squyres wrote: > On Jan 27, 2009, at 3:37 PM, Eugene Loh wrote: > >>> Jeff Squyres >>> Rich Graham >>> Brian Barrett >>> George Bosilca >>> Thomas Herault >>> Terry Dontje >> >> Is this Feb 11? How would it be if I attended? > > I'm a bozo -- I forgot to list you (even though Terry and I explicitly > discussed this); sorry! Yes, it would be great if you attended. > > -- > Jeff Squyres > Cisco Systems > > ___ > 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] Fun web site stats
Hi Jeff, Interesting, did the 1.2 downloads drop off because of lack of interest, or did it drop off because 1.3 became the default, 1.2 is no longer visible and the only reference is on the sidebar labeled as "old" ? Jim // Jeff Squyres wrote: Someone just asked me, so I pulled together a few fun web site stats: - We released Open MPI v1.3 on Jan 19, 2009 - I enabled Google Analytics tracking of v1.3 downloads on Jan 20 - From Jan 1, 2008 to Jan 20, 2009, there were 9,741 downloads of Open MPI v1.2 (including all sub-releases). This is about ~812/month, or ~187/week, or ~25/day - After Jan 20, 2009, the number of v1.2 downloads drops off sharply (we changed the default download links on the web site to point to v1.3) - From Jan 20-Jan 26, there have been 235 downloads of Open MPI v1.3, or ~39/day These numbers *should* include downloads from our mirrors, but I've never verified that. These numbers do not include nightly tarball downloads; they only include official release and release candidate tarballs and srpms. Browsers - 64% of our web site visitors use Firefox - 17% use IE - 7% use Safari Traffic sources - 68% of our traffic comes from Google searches - 13% of our traffic comes from people typing in "www.open-mpi.org" directly into their browser - 3% comes from www.lam-mpi.org - 2% comes from wikipedia Keywords - 22% search for "openmpi" (sigh) - 7% search for "open mpi" (I still have more work to do!) Visitors - 32% of visitors are from the USA - 7% are from Germany - 6% are from France - 5% are from Japan -- / Jim Langston Sun Microsystems, Inc. (877) 854-5583 (AccessLine) (513) 702-4741 (Cell) AIM: jl9594 jim.langs...@sun.com
[OMPI devel] Trunk broken at r20375
Hi folks I believe a recent commit has broken the trunk - I am unable to compile it on either Linux or Mac: In file included from convertor_raw.c:24: ../../ompi/datatype/datatype_pack.h: In function ‘pack_predefined_data’: ../../ompi/datatype/datatype_pack.h:41: error: implicit declaration of function ‘MEMCPY_CSUM’ convertor_raw.c: In function ‘ompi_convertor_raw’: convertor_raw.c:60: warning: format ‘%p’ expects type ‘void *’, but argument 4 has type ‘struct iovec *’ convertor_raw.c:60: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 5 has type ‘unsigned int’ convertor_raw.c:60: warning: format ‘%p’ expects type ‘void *’, but argument 6 has type ‘long unsigned int’ convertor_raw.c:87: warning: comparison between signed and unsigned make[2]: *** [convertor_raw.lo] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 Perhaps an include file is missing? Thanks Ralph
Re: [OMPI devel] Trunk broken at r20375
Actually, check that - it seems to be building under Linux (my build broke in some other area where I am working, but not here). However, it does not build on the Mac. Any suggestions? Ralph On Jan 28, 2009, at 12:19 PM, Ralph Castain wrote: Hi folks I believe a recent commit has broken the trunk - I am unable to compile it on either Linux or Mac: In file included from convertor_raw.c:24: ../../ompi/datatype/datatype_pack.h: In function ‘pack_predefined_data’: ../../ompi/datatype/datatype_pack.h:41: error: implicit declaration of function ‘MEMCPY_CSUM’ convertor_raw.c: In function ‘ompi_convertor_raw’: convertor_raw.c:60: warning: format ‘%p’ expects type ‘void *’, but argument 4 has type ‘struct iovec *’ convertor_raw.c:60: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 5 has type ‘unsigned int’ convertor_raw.c:60: warning: format ‘%p’ expects type ‘void *’, but argument 6 has type ‘long unsigned int’ convertor_raw.c:87: warning: comparison between signed and unsigned make[2]: *** [convertor_raw.lo] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 Perhaps an include file is missing? Thanks Ralph
Re: [OMPI devel] Trunk broken at r20375
Rats - once I fixed my area, it again broke on Linux at this same spot in convertor. Sorry for the confusion Ralph On Jan 28, 2009, at 12:25 PM, Ralph Castain wrote: Actually, check that - it seems to be building under Linux (my build broke in some other area where I am working, but not here). However, it does not build on the Mac. Any suggestions? Ralph On Jan 28, 2009, at 12:19 PM, Ralph Castain wrote: Hi folks I believe a recent commit has broken the trunk - I am unable to compile it on either Linux or Mac: In file included from convertor_raw.c:24: ../../ompi/datatype/datatype_pack.h: In function ‘pack_predefined_data’: ../../ompi/datatype/datatype_pack.h:41: error: implicit declaration of function ‘MEMCPY_CSUM’ convertor_raw.c: In function ‘ompi_convertor_raw’: convertor_raw.c:60: warning: format ‘%p’ expects type ‘void *’, but argument 4 has type ‘struct iovec *’ convertor_raw.c:60: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 5 has type ‘unsigned int’ convertor_raw.c:60: warning: format ‘%p’ expects type ‘void *’, but argument 6 has type ‘long unsigned int’ convertor_raw.c:87: warning: comparison between signed and unsigned make[2]: *** [convertor_raw.lo] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 Perhaps an include file is missing? Thanks Ralph ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] Trunk broken at r20375
Seems more like a compiler problem. A static inline function defined in the header file but never used is the source of the problem. It did compile for me with the gcc from Leopard and 4.3.1 on Linux. I'll commit the fix asap. george. On Jan 28, 2009, at 14:26 , Ralph Castain wrote: Rats - once I fixed my area, it again broke on Linux at this same spot in convertor. Sorry for the confusion Ralph On Jan 28, 2009, at 12:25 PM, Ralph Castain wrote: Actually, check that - it seems to be building under Linux (my build broke in some other area where I am working, but not here). However, it does not build on the Mac. Any suggestions? Ralph On Jan 28, 2009, at 12:19 PM, Ralph Castain wrote: Hi folks I believe a recent commit has broken the trunk - I am unable to compile it on either Linux or Mac: In file included from convertor_raw.c:24: ../../ompi/datatype/datatype_pack.h: In function ‘pack_predefined_data’: ../../ompi/datatype/datatype_pack.h:41: error: implicit declaration of function ‘MEMCPY_CSUM’ convertor_raw.c: In function ‘ompi_convertor_raw’: convertor_raw.c:60: warning: format ‘%p’ expects type ‘void *’, but argument 4 has type ‘struct iovec *’ convertor_raw.c:60: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 5 has type ‘unsigned int’ convertor_raw.c:60: warning: format ‘%p’ expects type ‘void *’, but argument 6 has type ‘long unsigned int’ convertor_raw.c:87: warning: comparison between signed and unsigned make[2]: *** [convertor_raw.lo] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 Perhaps an include file is missing? Thanks Ralph ___ 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] Trunk broken at r20375
Thanks George! It wouldn't compile for me on my Leopard or on any of our Linux clusters, nor on the IU odin Linux cluster. Not sure why - all were with different versions of gcc. Thanks again Ralph On Jan 28, 2009, at 2:48 PM, George Bosilca wrote: Seems more like a compiler problem. A static inline function defined in the header file but never used is the source of the problem. It did compile for me with the gcc from Leopard and 4.3.1 on Linux. I'll commit the fix asap. george. On Jan 28, 2009, at 14:26 , Ralph Castain wrote: Rats - once I fixed my area, it again broke on Linux at this same spot in convertor. Sorry for the confusion Ralph On Jan 28, 2009, at 12:25 PM, Ralph Castain wrote: Actually, check that - it seems to be building under Linux (my build broke in some other area where I am working, but not here). However, it does not build on the Mac. Any suggestions? Ralph On Jan 28, 2009, at 12:19 PM, Ralph Castain wrote: Hi folks I believe a recent commit has broken the trunk - I am unable to compile it on either Linux or Mac: In file included from convertor_raw.c:24: ../../ompi/datatype/datatype_pack.h: In function ‘pack_predefined_data’: ../../ompi/datatype/datatype_pack.h:41: error: implicit declaration of function ‘MEMCPY_CSUM’ convertor_raw.c: In function ‘ompi_convertor_raw’: convertor_raw.c:60: warning: format ‘%p’ expects type ‘void *’, but argument 4 has type ‘struct iovec *’ convertor_raw.c:60: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 5 has type ‘unsigned int’ convertor_raw.c:60: warning: format ‘%p’ expects type ‘void *’, but argument 6 has type ‘long unsigned int’ convertor_raw.c:87: warning: comparison between signed and unsigned make[2]: *** [convertor_raw.lo] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 Perhaps an include file is missing? Thanks Ralph ___ 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
