Conference call notes 20190109 - easybuilders/easybuild GitHub Wiki

(back to Conference calls)

Notes on the 117th EasyBuild conference call, Wednesday Jan 9th 2019 (17:00 - 18:00 CET)

Attendees

Alphabetical list of attendees (7):

  • Damian Alvarez (JSC, Germany)
  • Mikael Öhman (Chalmers University of Technology, Sweden)
  • Victor Holanda (CSCS, Switzerland)
  • Kenneth Hoste (HPC-UGent, Belgium)
  • Bart Oldeman (ComputeCanada)
  • Åke Sandgren (Umeå University, Sweden)
  • Davide Vanzo (Vanderbilt University, US)

Agenda

  • updates on upcoming EasyBuild v3.8.1
  • 2019a update of common toolchains
  • update on porting EasyBuild to Python 3
  • Q&A

Outlook to EasyBuild v3.8.1

2019a update of common toolchains

  • foss/2019a: https://github.com/easybuilders/easybuild-easyconfigs/pull/7371

    • OpenMPI 4.0.0 drops old MPI APIs, so not a good idea to use that OpenMPI 3.1.3
      • breaks ScaLAPACK 2.0.2 for example (Åke has a fix)
      • see OpenMPI release notes
    • Victor: what about fosscuda (CUDA is not compatible with GCC 8.2 yet)
      • Davide/Åke: not updates for now beyond fosscuda/2018a

  • intel/2019a: https://github.com/easybuilders/easybuild-easyconfigs/pull/7372

    • Damian: Intel MPI 2019 update 1 is problematic with "big" jobs (>1.5k (24*64) cores)
      • main problem is with collectives (and libfabric mostly deals with P2P connections)
      • can be triggered with Intel MPI benchmarks on GitHub
      • Åke: OFED stack + IB cards?
        • OFED 10 + Mellanox
          • also in different system
      • Bart: there's a new libfabric release that may fix the problem
        • Damian: Intel MPI has official support to use separate libfabric as a dependency (and it's documented)
      • this seems like a blocker to use impi 2019.01 in intel/2019a
        • go forward with impi 2018 update 4 instead (is used in production at JSC with 2019 Intel compilers/MKL)

Update on porting EasyBuild to Python 3

Other

  • pigz PR (https://github.com/easybuilders/easybuild-easyconfigs/pull/7346) raised back a previously reported problems

  • Mikael: update/thoughts on bringing Python down to GCCcore level?

    • cfr. post on EB mailing list
    • only build Python interpreter once, doesn't make sense to build once with intel, once with foss
    • performance benchmarking done with Intel vs GCC build for Python by Damian
      • significant diff for 'exp' function, but only for scalars (cfr. https://github.com/numpy/numpy/issues/8823)
      • Bart has also experimented with this
        • numpy performance is hit by libm already being in memory for libpython
          • forcing it to use libimf requires static linking or preloading libimfo
        • some serious tuning in recent glibc versions, more competitive with Intel's libimf
      • not a clear win for Intel vs GCC, unclear how/if it actually affects real production code in practice
    • JSC is already using "core" Python vs SciPy module (to build numpy with imkl)
    • Mikael's approach:
      • preserving user experience by defining separate 'PythonCore' lib
      • prime issue w.r.t. graphics libs like Qt5 at GCCcore level (which needs Mesa, which needs Python for bindings)
    • we should consider lowering Python to GCCcore as a community policy
      • maybe too tight to go through with this for 2019a common toolchains?
      • we should try and find something that most people are happy with...
    • at JSC: shadowing of Python interpreter when SciPy module is loaded was done before
      • approach now is different: SciPy is now down at GCCcore level too (just like imkl)
      • Mikael has seen problems with ABI compatibility problems with an approach like this
    • Mikael has a relevant PR to fix a linking issue in Python
      • cfr. framework PR
    • follow-up during next conf call, Mikael can look into alternatives and present them