search

MCSclimate / MCT

Model Coupling Tookit
Other
43 stars 18 forks source link

GSMap::haloed_ is slow #29

Open rljacob opened 9 years ago

rljacob commented 9 years ago

(copied from MCT's old bugzilla)

reported by @worleyph: "A second performance problem is due to 3 calls to the function GlobalSegMap_haloed in AVComms of the form ..

if(GlobalSegMap_haloed(GSMap)) then

or

< if(haloed_(pointGSMap)) then (in GSMap::Pelocs

As noted in the comments of the function haloed_, this can be expensive. It is currently called multiple times for the same global seg. map. I do not understand the logic or ramifications, but I made the assumption that whether a GSMap is haloed or not is a characteristic set at creation time. So, I added a new field to the GlobalSegMap type:

  logical :: haloed                ! Haloed?

and then set this field at the end of initr, initp, and initp1 . (I don't know what to do about initp0 .) I got bit-for-bit results with this one benchmark problem. I do not know if this is the correct approach and/or correct implementation, but we do NOT want to be recomputing haloed_ over and over again on the same global seg. map.

This drops the execution time by another 2-3% on 1024 nodes of BG/P."

rljacob commented 9 years ago

(Copied from MCT's old bugzilla)

There's only one call to haloed in AvComms. Its in GSM_gather which is checking for a fail condition (if the input GSMap is haloed.) The only other calls are in GSMaps::pelocs (also checking for a fail condition) and in ConvertMaps::GlobalSegMapToGlobalMap