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

MPI: Experimental platform tag #4073

Closed
wants to merge 5 commits into from
Closed

Conversation

vchuravy
Copy link
Member

L/LAMMPS/build_tarballs.jl Outdated Show resolved Hide resolved
L/LAMMPS/build_tarballs.jl Outdated Show resolved Hide resolved
# Dependencies that must be installed before this package can be built
dependencies = [
Dependency(PackageSpec(name="CompilerSupportLibraries_jll")),
Dependency(PackageSpec(name="MPItrampoline_jll"), compat="2"),
Dependency(PackageSpec(name="MicrosoftMPI_jll"))
# Dependency(PackageSpec(name="MPIPlatformTag")),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@staticfloat @simonbyrne

I am debating if this should be MPI.jl or a tiny single preference package.

@giordano giordano mentioned this pull request Dec 19, 2021
@simonbyrne
Copy link
Contributor

How does this work if you have another _jll which depends on LAMMPS_jll: would it automatically augment the platform?

@staticfloat
Copy link
Member

Each JLL chooses its own artifacts in isolation from eachother; if LibFoo_jll depends on LAMMPS_jll, if LAMMPS_jll chooses one based on a particular MPI backend, then if LibFoo_jll's own artifacts are similarly sharded across MPI backends, it must perform the same steps as LAMMPS_jll does.

This is intentional; we don't want artifact selection to be involved in resolution. If you need to solve for resolution constraints, you should have multiple packages. You should only use artifact tags when you have identical (or nearly so) functionality that can be swapped out without changing any other package's compatibility bounds.

As an analogy, If I instantiate a bunch of packages that have multiple artifacts that are split into micro-architectural optimized builds (e.g. x86_64, sse2, avx, avx2), then instantiating with a different micro-architecture (because I've upgraded the CPU in my machine, for example) shouldn't cause any dependent packages to suddenly become non-functional. This is the intended design of the artifact selection mechanism, partly because there is no graceful failure case. There's no way for Foo_jll to say "I'm sorry, I can't select an artifact properly because Bar_jll selected something incompatible with me".

There is a gray area here where you're coordinating the choice of backend/dialect across multiple JLLs. I think this is still okay, because we are essentially asserting that all MPI-supporting JLLs must obey a centralized MPI backend setting. This should work flawlessly, with the exception that if we have JLLs that hasn't been updated to pay attention to MPI tags, we may get a mixture. This may be fixable through intelligent compat bounds, to ensure that we only have MPI-tag-aware JLLs installed together.

@vchuravy
Copy link
Member Author

vchuravy commented Mar 3, 2022

Replaced by #4540

@vchuravy vchuravy deleted the vc/augmented_platform branch March 3, 2022 22:32
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

Successfully merging this pull request may close these issues.

3 participants