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

[WIP/RFP] Secondary subtoolchains #2234

Closed

Conversation

bartoldeman
Copy link
Contributor

With the introduction of the iimkl (Intel + MKL without MPI) toolchain in our software stack it could not be a subtoolchain with the current infrastructure. In fact the subtoolchain structure becomes a DAG:

   iomkl
   /    \
iompi iimkl
   \     /
   iccifort
      |
   GCCcore
      |
   dummy

This patchset changes iomkl to have two subtoolchains. However it does not implement a DAG, as it assumes that the sub-subtoolchains of iomkl (the subtoolchains of iimkl and iompi, that is, iccifort) are identical.

This is sufficient for our setup but feels a bit quick and dirty. Please let me know what you think.

@bartoldeman bartoldeman changed the base branch from master to develop May 31, 2017 13:57
from easybuild.toolchains.fft.intelfftw import IntelFFTW
from easybuild.toolchains.linalg.intelmkl import IntelMKL


class Iomkl(Iompi, IntelMKL, IntelFFTW):
class Iomkl(Iompi, Iimkl, IntelMKL, IntelFFTW):
Copy link
Member

@ocaisa ocaisa May 31, 2017

Choose a reason for hiding this comment

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

Since you're inheriting from Iimkl you don't need to also inherit from IntelMKL, IntelFFTW (they're already there)

Copy link
Member

Choose a reason for hiding this comment

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

+1, but this may have impact on how toolchains are verified by EasyBuild (not sure though)

@ocaisa
Copy link
Member

ocaisa commented May 31, 2017

What does the toolchain hierarchy output look like after this?

@ocaisa
Copy link
Member

ocaisa commented May 31, 2017

For me, I'm ok with the concept but I do think you should be verifying that the underlying toolchains of iimkl and iimpi are consistent...but I think that may already be happening because I believe there is already a uniqueness check in the toolchain hierarchy.

@bartoldeman
Copy link
Contributor Author

For toolchain output you mean this using --info? This is using minimal toolchains including dummy:

INFO Found toolchain hierarchy for toolchain {'version': '2016.4', 'name': 'iomkl'}: [{'version': '', 'name': 'dummy'}, {'version': '5.4.0', 'name': 'GCCcore'}, {'version': '2016.4', 'name': 'iccifort'}, {'version': '2016.4', 'name': 'iompi'}, {'version': '2016.4', 'name': 'iimkl'}, {'version': '2016.4', 'name': 'iomkl'}]

@@ -134,6 +134,71 @@ def cache_aware_func(toolchain):

return cache_aware_func

def get_subtoolchain_in_deps(parsed_ec, subtoolchain_name, current_tc_name):
Copy link
Member

Choose a reason for hiding this comment

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

@bartoldeman This is begging for a dedicated unit test, to verify that it works as intended (and doesn't get broken in the future somehow)...

# only retain candidates that match subtoolchain name
cands = [c for c in cands if c['name'] == subtoolchain_name]
if isinstance(subtoolchain_name, list):
for name in subtoolchain_name[1:]:
Copy link
Member

Choose a reason for hiding this comment

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

please clarify with a comment why you are skipping the 1st subtoolchain?

@boegel
Copy link
Member

boegel commented Jun 21, 2017

@bartoldeman This gives you a flat list, i.e. not a DAG, which basically means there's an order implied between iompi and iimkl, while there is none. I.e., either of both will be considered first, while in a DAG you would treat both equally, and act accordingly when there's a hit for both of them.

That's not necessarily a big issue though, since which one you pick may not matter too much, and having a hit for both may actually not happen in practice: software that doesn't depend on MPI would only have an easyconfig with iimkl, while something that doesn't depend on MPI would only be there with iompi...

So, I think this is OK. I assume this work as intended for you? Do you have some practical examples?

@boegel boegel added this to the 3.4.0 milestone Jun 21, 2017
@bartoldeman
Copy link
Contributor Author

Hello Kenneth, Alan,

thanks for the feedback! Yes this is working as intended for us. One example I have is mpi4py (iomkl), which depends on numpy or in our case the scipy stack module (iimkl).

I won't have time to work on this this week though. It will have to wait until next week or the week there after. Our nix+easybuild stack is moving into production so these are exciting but busy times.

Bart

@boegel boegel modified the milestones: 3.4.0, 3.x Sep 4, 2017
bartoldeman added a commit to ComputeCanada/easybuild-framework that referenced this pull request Apr 4, 2018
This PR replaces easybuilders#2234.
subtoolchains are now searched using a breadth-first-search, which
allows multiple subtoolchains per toolchain.

Some subtoolchains such as golf and golfc are now marked OPTIONAL
since they do not have to exist as modules, and can be skipped.

Since those optional subtoolchains cannot usually be found via a
dependency search (as toolchain easyconfigs do not typically have
subtoolchains as dependencies)
try to search for subtoolchain/version with the same version as
the parent. E.g. goolfc/2.6.10 searches for golfc/2.6.10, and
golfc/2.6.10 searches for golf/2.6.10 and gcccuda/2.6.10.
@bartoldeman bartoldeman closed this Apr 4, 2018
bartoldeman added a commit to ComputeCanada/easybuild-framework that referenced this pull request Aug 29, 2018
This PR replaces easybuilders#2234.
subtoolchains are now searched using a breadth-first-search, which
allows multiple subtoolchains per toolchain.

Some subtoolchains such as golf and golfc are now marked OPTIONAL
since they do not have to exist as modules, and can be skipped.

Since those optional subtoolchains cannot usually be found via a
dependency search (as toolchain easyconfigs do not typically have
subtoolchains as dependencies)
try to search for subtoolchain/version with the same version as
the parent. E.g. goolfc/2.6.10 searches for golfc/2.6.10, and
golfc/2.6.10 searches for golf/2.6.10 and gcccuda/2.6.10.
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