[mpich-discuss] Faster MPI_Attr_get?

[Jeff Squyres]

On May 11, 2012, at 2:31 PM, Jed Brown wrote:

> Well, attributes are critical for library interoperability. Libraries would need horrible work-arounds if it didn't exist.

Fair enough -- that's why they're there.  But still, the assumption is that their performance didn't matter.

> In this case, we are stashing a "thread communicator" as an attribute, so we access it each time a thread pool is sparked. There is an OpenMP implementation of thread communicator, but also using other threading models and raw pthreads (which is somewhat lower overhead because our model is less synchronous).
> 
> The ca. 1000 cycle MPI_Attr_get makes it dominate the overhead to spark threads. A simple-minded cache speeds it up a lot, but it would be cleaner to just use MPI_Attr_get.

Interesting use case.  Like Dave, seeing a small benchmark would be helpful -- particularly if you can make it multi-threaded (sets and gets going on concurrently).  A whole new area of MPI to optimize!  ;-)  (and make thread safe! which, I'm guessing, will be the tricky part to optimize...)

Per Jeff H's, comment, yes, it is MPI_COMM_GET|SET_ATTR (and friends), but you're right that most (if not all?) MPI implementations directly re-use the same code as MPI_ATTR_GET|SET, because none of the parameters changed in C between the two.

-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/