[flang-commits] [flang] [mlir] [Flang][OpenMP] Privatize descriptors for assumed shape array maps for performance increase (PR #212336)

[via flang-commits]

agozillon wrote:

> This more or less lgtm to me but i have a couple of high-level points
> 
> 1. It would be good to include performance improvement numbers, if you have them handy, from the reduced DMA of a the descriptor.

Sure, but it doesn't really have a place being in-lined in the PR, other than perhaps in the commit description however, it's unlikely to have context without the program itself:

**| Configuration | 1 Argument | 2 Arguments | 3 Arguments |** 
Regular Explicit Shape Array | 28.716 | 33.918 | 38.631 
Assumed Size — No Elision + Privatization | 34.893 | 41.283 | 54.379 | 
Assumed Size — Original (No Optimization) | 52.109 | 79.250 | 113.348 |

Time is in seconds, they're reasonably large arrays, the arguments correspond to number of array inputs to the function, the functions have a target region with and they are being invoked many times in a loop to get the end result, it mimics some real world code, albeit I'm sure like most of these things it could be re-implemented more optimally but they'd rather not :-)

> 2. Somewhere in the comments, could you please explain what "privatization" of a descriptor is. I had to look at the runtime code to get an understanding of what privatization in teh context of a descriptor meant. I get how target_param is used, but it would have helped greatly to have an explanation for "privatization". 

I can, although, I'm not sure I can word or extend it much more than the runtime or the specification actually words it. It is effectively just firstprivatizing the descriptor, the same as you'd do for things like scalars. It just looks like something different as the machinery behind it is a little more complicated as it needs to handle attachment and the runtime has to do a little more book-keeping. Just because something is privatized doesn't mean there isn't some mechanism for transferal that goes on, e.g.  anything firstprivate or lastprivate, and these come as target_param's as they require an actual kernel argument, same as almost every other data transfer outside of declare target (I'm aware you know this and likely a lot of other bits and pieces I state here, but for other possible readers). The main aspect of all this is that it's just significantly more performant to do this, as instead of a separate H2D call for every descriptor, you batch them into a single H2D transfer that piggy backs on the initial kernel launch payload, effectively condensing the amount of data transfers (not total data) required and runtime book keeping needed. 

It's also more correct unless a user is explicit about things utilizing ref semantics, the descriptor should have no write-back or side-effects from the kernel. In certain more complicated parallel cases it's required for code correctness, but we're not quite there yet. This is something the existing Intel compiler already does.

> Having said that, i see that the term is used pretty liberally throughout the PR so if this is documented somewehre, please include a link.

I think unfortunately like most things in LLVM and the runtime, you're not going to find documentation lying around for this, other than the self-documenting aspect of the actual runtime code itself, contributors can look up the originating PR for most of this stuff, I could add a link to the PRs, but they'll grow stale with time  :-) 


https://github.com/llvm/llvm-project/pull/212336