Hi Marc-Andre, all,
Thanks for the notes and sorry I couldn’t make it last week. Looking over the notes I have a few questions/comments on QMPI (not necessarily for you, but for the group):
Re: "Implementations define an enum that can be used to query.”
That certainly works and is probably relatively clean. If we go that way, though, we should prescribe the enum values in the standard. We should also leave the option for MPI implementations to add more than the existing standardized calls (e.g., now MPIX functions) to that array, e.g., after a cutoff index.
Re: "What about symbol name length”
What speaks against just using the existing MPI function names as enum elements? Then we at least don’t introduce any new problems.
Re: "How would QMPI know the name of the wrappers of a linked tool?”
I had thought about this before as well, but I think this can lead to problems - if you end up with two tools using the same prefix (like the “tool” in the example - I imagine we put this into the examples and there every 2nd tool will be called “tool”, no matter how many advice to users we write). It would also require MPI to do a dlsym on every node at startup for every tool for every MPI function, which probably causes scalability issues.
I am not sure we need it though: if MPI passes a void* array with the index enum from above during the init function, then the tool can fill it out and just write all its own function pointers into the array and then hand that back to MPI for the creation of the larger tables.
Re: "Current prototype focuses/relies on dynamic libraries”
With the above function table method, I think the system should already support static libraries - as long as they get initialized somehow, they can register themselves and their functions (function pointers work equally for static libraries).
Cheers,
Martin
—
Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems
Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching
Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ)