Hi Jeff, >> 1. How about evaluating FUNNELED and SERIALIZED performance ? > > For Open MPI, it's basically THREAD_MULTIPLE and not-THREAD_MULTIPLE. I.e., > there's no real difference between SINGLE, SERIALIZED, FUNNELED
We were assuming that there would be cost due to locking/synchronization in FUNNELED and SERIALIZED also. Hence, the previous question. We will run some tests using osu_mbw_mr benchmark and update. > Does that make sense? Yes, it does :) Thanks a lot for the explanation. Thanks, - Sreenidhi. On Wed, Jul 27, 2016 at 7:57 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> wrote: > On Jul 27, 2016, at 7:32 AM, Sreenidhi Bharathkar Ramesh > <sreenidhi-bharathkar.ram...@broadcom.com> wrote: >> >> hi Jeff, >> >> This is interesting topic. Just FYI, we were thinking of evaluating >> threading performance using the following: >> http://www.mcs.anl.gov/~thakur/thread-tests/thread-tests-1.1.tar.gz ; OSU >> MB also seems good to measure. > > Some of those tests are good, some are not. Some of them are more of a test > of unexpected messages, for example -- and don't really do a good job of > isolating threading effects from other effects. > >> 1. How about evaluating FUNNELED and SERIALIZED performance ? > > For Open MPI, it's basically THREAD_MULTIPLE and not-THREAD_MULTIPLE. I.e., > there's no real difference between SINGLE, SERIALIZED, FUNNELED. > >> 2. Is there any discussion or proposal on optimizing / improving thread >> performance ? > > That's what this is all about. THREAD_MULTIPLE support has been... "nominal" > in Open MPI for a few years. v2.0.0 took some major leaps forward in terms > of MPI_THREAD_MULITIPLE correctness and performance in its core > infrastructure. As part of that effort, the MPI_Request handling was > revamped. > > Solid, performant THREAD_MULTIPLE support is new ground in many ways. This > is a journey that will take some time (i.e., improve over the span of > multiple releases). We took several important steps forward in v2.0.0, and > now we need to a) quantify those steps, and b) decide what the next steps > will be. > > Over the past 3-4 weeks on the weekly webex, we've been discussing improving > both of these things: > > - quantifying our current THREAD_MULTIPLE performance > - quantifying exactly what the MPI_Request revamp improves (and doesn't > improve) > > Yesterday on the webex, we had a lengthy discussion about exactly these > issues. > > The action item that Arm+I took from that conversation was to run some thread > performance measurement tests. ...but when Arm started running tests > yesterday afternoon, it quickly became evident that we didn't know exactly > *what* data to collect, and what the *specific* end goals were for collecting > that data. > > So Arm and I stopped running tests, and instead sat down for 2-3 hours and > came up with the proposal that we published on the wiki for discussion / > comment. > > Does that make sense? > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2016/07/19302.php _______________________________________________ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
