Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Information about backend support missing? #43

Closed
olesenm opened this issue Apr 22, 2024 · 3 comments
Closed

Information about backend support missing? #43

olesenm opened this issue Apr 22, 2024 · 3 comments

Comments

@olesenm
Copy link

olesenm commented Apr 22, 2024

Although this project looks somewhat dead, I did have some questions:

The idea of chucking really large messages into a new data type looks quite appealing. However, it's not clear if the various backends (eg, infiniband) would actually support sizes greater than 2^31.
Any central information about this available?

@jeffhammond
Copy link
Owner

jeffhammond commented Apr 22, 2024

The project is maintained (bugs will be fixed) but not developed (features will not be added). Once the feature set I proposed made it into MPI 4.0, I moved on to other things.

Many of the back-ends for MPI, e.g. UCX, already support size_t counts, in which case they should be fine already. There may still be implementation bugs, of course. There have been discussions lately about how to test MPICH better, for example.

If you find things don't work somewhere, please report them and I'll do my best to help. I have access to a pretty good range of hardware.

@olesenm
Copy link
Author

olesenm commented Apr 23, 2024

Wow - fast feedback, and great offer too! At the moment, I was considering that I might just be able to incorporate some of your bigmpi ideas without the whole thing, since we already have an encapsulated interface to MPI. It looks like would "only" need to mimic your conditional creation of the new MPI datatype and then test, test, test.

In your code you have the BigMPI_Factorize_count : just playing about? or useful/critical? I don't really have a feeling for how expensive the type creation and freeing is.

@jeffhammond
Copy link
Owner

yes, allowing others to borrow what they need from BigMPI and integrate into their own projects to avoid another dependency was an explicit design goal.

BigMPI_Factorize_count is not strictly necessary and it seems BIGMPI_AVOID_TYPE_CREATE_STRUCT isn't defined by default so it shouldn't be compiled.

BigMPI_Factorize_count exists so that one can use a vector rather than a struct datatype. in any reasonable implementation of MPI, both will be recognized as a big contiguous slab and optimized to the same thing. i haven't verified this but implementers tell me it's true.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants