Sept. 20, 2018 — Spack, a Lawrence Livermore National Laboratory-developed open source package manager optimized for high performance computing (HPC), is making waves throughout the HPC community, including internationally, as evidenced by a recent tour of European HPC facilities by the tool’s developers.

Despite its niche status, Spack (short for Supercomputer PACKage manager), is one of the most popular pieces of software the Lab has ever released to the GitHub open source community. Described by its developers as “an app store for supercomputers,” Spack was started by LLNL computer scientist Todd Gamblin in 2013 and has quickly become the go-to package manager at LLNL and Argonne, Oak Ridge, Los Alamos and Sandia national laboratories, as well as Lawrence Berkeley’s National Energy Research Scientific Computing Center (NERSC). Not only is it being used on the Department of Energy’s (DOE) latest and greatest flagship systems, Oak Ridge’s Summit and LLNL’s Sierra, it’s also become the official deployment tool for the Exascale Computing Project, the “glue” for coordinating exascale software releases and deploying them to HPC facilities.

“It’s been pretty amazing,” Gamblin said of Spack’s rise to broad acceptance. “It wrecks my inbox — I get 200 emails a day about Spack from GitHub and the mailing list — but the momentum is great. We continue to drive development, and we review features and merge bug fixes, but the community helps tremendously with new ideas, new features and regular maintenance. I don’t think we could sustain a project of this scale without their help.”

Perhaps nothing has epitomized Spack’s growing reach more than the month of July, which began with Gamblin presenting Spack at the Platform for Advanced Scientific Computing (PASC) Conference in Basel, Switzerland, piquing interest from France’s Atomic Energy Institute (CEA) and other institutions. From there, Gamblin took a day trip to the Technical Institute of Munich (TUM), where he discussed potential collaborations with former LLNL computer scientist Martin Schulz, who is now TUM’s chair professor for Computer Architecture and Parallel Systems, as well as staff at the affiliated Leibniz Supercomputing Centre (LRZ). LRZ is deploying a 26-petaflop supercomputer called SuperMUC-NG and is planning to use Spack to set up the machine’s software.

Gamblin then drove to Lausanne, Switzerland, to visit École polytechnique fédérale de Lausanne (EPFL) on July 6, where he was joined by fellow LLNL computer scientist Greg Becker, who is part of the Spack team and has been instrumental to its development. While there, the pair met with longtime Spack contributor Massimiliano Culpo, who uses Spack to manage software on EPFL’s supercomputers. From Lausanne, they drove to Paris for a visit at CEA facilitated by LLNL computer scientist Edgar Leon, who is on a yearlong visiting assignment at the facility. CEA is interested in using Spack to modernize its developer workflow, Gamblin said, and the group discussed adding features to support the institute’s work and ways that CEA and LLNL could work together on future Spack features.

After enjoying a festive evening in Paris as the French celebrated their win over Belgium in the World Cup, Gamblin returned to the States, and Becker went on to London and the Atomic Weapons Establishment (AWE), which is exploring package deployment with Spack. Becker spent more than a week at AWE and met with British scientists involved in the Joint Working Group, a treaty-based high performance computing partnership between LLNL and the U.K.’s Science and Technology Facilities Council aimed at improving industry, promoting collaborations and boosting economic competitiveness.

Gamblin and Becker said the trip was useful in picturing what other HPC sites are attempting to do with Spack, figuring out what features to focus on next and starting a conversation about new collaborations. It also left them thinking they needed to expand community outreach. Since the meeting, Gamblin and collaborators from CEA and LRZ have had a birds-of-a-feather session accepted at the upcoming Supercomputing Conference 18 (SC18) in Dallas, where they will have a larger face-to-face community meeting. Gamblin and others will also hold a Spack tutorial at SC18.

“I think we got a lot of feedback that was some version of ‘Wow, this fills a use case that nothing else really does for me, and it would be great if it had these features, too,’” Becker said. “People definitely weren’t shy about letting us know what they hoped we were planning on doing or what they were planning on submitting, but they were very clear that they had looked at everything they could find out there and there wasn’t anything else that was going this direction.”

Spack has come a long way in the few short years since Gamblin first started coding it on weekends in coffee shops. He built the first version, a Python-based program that would automatically build libraries on the Lab’s Linux machines, to help his summer students by freeing them up to do their work. Subsequent Lab Hackathons attracted additional contributors and more packages, and after Gamblin presented a paper on Spack at Supercomputing Conference (SC15), interest began pouring in from other Department of Energy national laboratories, academia and companies with HPC resources.

“After SC15 my inbox exploded,” Gamblin said. “There were days where I would check my mail and think ‘how am I going to sustain this?’”

Through the open source repository GitHub, Spack has attracted hundreds of users who have added software packages (Spack now supports 2,800 of them), and HPC centers like NERSC, EPFL, Fermilab and the European Organization for Nuclear Research (CERN) have contributed significant features. Gamblin, Becker, and Peter Scheibel (GS) work to evaluate contributions from all of these organizations. The three also have appeared on HPC-related podcasts and conferences, including tutorials at SC16 and SC17, to spread the word about Spack’s usefulness and versatility.

“It’s like the app store for HPC, but the tricky bit of HPC is that we want 15 different configurations of the same app at once,” Becker said. “One of the key things for Spack is that the underlying model allows us to satisfy that need.”

The reasons for Spack’s popularity among the HPC community, Gamblin said, are twofold. Most system package managers require users to run with superuser privileges, which is fine for most developers because they own their machines. But HPC machines are shared, he explained, and Spack can install a lot of low-level software as a regular user in their home directory.

“For the HPC space it definitely fills a gap,” Gamblin said. “People needed something that could install custom packages in their own directory. The fact that you can run as a user is a big deal. There are other systems, like EasyBuild, that also have traction in this space, but they are very much targeted at system administrators rather than computational scientists. Spack gives you additional flexibility that both administrators and developers need.”

Another advantage, Gamblin said, is that other package managers that targeted developers are specific to a certain programming language, such as npm for Javascript, or Bundler for Ruby. HPC software crosses languages (C++, Python, Fortran etc.) so the relationships between packages are inherently more complex.

“Integrating so many packages into one application from so many different software ecosystems makes HPC particularly hard,” Gamblin said. “HPC software is more complicated today than 10 years ago. There are more dependencies, libraries and integration, so the need became more acute.”

Also working in Spack’s favor is that a lot of HPC labor involves porting software over to new machines, as LLNL is currently doing with Sierra. While most package managers are specific to one machine, Spack packages are templated, so if developers write a package for one machine, Becker said the likelihood is higher that it will work on another machine.

“If you get on a platform that no one’s ever tried to build this on before, Spack will at least make a best effort,” Becker said. “If that platform is really weird, it might not get very far, but in many cases, the best effort works.” This is the flexibility that Spack offers that other systems don’t.

Today, Spack is used by 40-50 people at LLNL, mostly developers in Livermore Computing (LC) and other parts of the Lab, as well as code teams who are using it as the interface to install scientific packages to run on Linux cluster machines, including Blue Gene/Q and Sierra. Spack has reduced the time needed to deploy complex codes on certain Lab supercomputers from weeks to days.

“We’re moving toward using Spack exclusively to deploy user-facing software in LC, but we’re moving from our current process, which uses Spack to generate RPM packages for the system package manager,” Becker said. “We have a fair number of people in the development environment group who use Spack to feed packages into that process. I think we’re collectively using it at every level in the hierarchy: single-user, application teams and system deployments.”

Gamblin and the Spack team, including its outside contributors, are working on new improvements and features with hopes of releasing version 1.0 in November, possibly at SC18. Gamblin said that in the coming year, they plan to add features that enable facilities to deploy extremely large suites of software easily, as well as features that simplify the workflow for individual developers working on multiple projects at once. The team is calling these features “Spack Stacks” and “Spack Environments,” respectively.

While optimized for supercomputers, Spack also can be used on home computers and laptops, where Gamblin and others see the potential for wider acceptance. Gamblin said he wants to include more machine learning libraries, to allow users to combine those workflows with HPC using the same tool. The Spack team also is looking to focus on greater reproducibility from one stack to another, polishing workflows and working on better support for binary software packages.

Additionally, Gamblin said he would like to expand community engagement and explore a steering committee that could govern future Spack-related decisions. Gamblin, Becker and others want Spack to eventually be part of the general deployment strategy for libraries across DOE. Spack has been adopted as the deployment tool for the U.S. Exascale Computing Project’s (ECP’s) software stack, and other DOE national labs are gradually joining in the fray.

“It’s nice to have industry standards where possible, and it would be great if we could fill that role in terms of getting everyone on the same page,” Becker said. “Spack is already good at the individual level of avoiding duplication of work and if we could keep on extending that so that large HPC sites are able to share work with each other, that would be great as well.”

“I’d like it if Spack were the way people use supercomputers and if it were part of everyone’s development environment. Good package management helps to grease the wheels,” Gamblin added. “The dream is to take the grunt work out of HPC: users get on a machine, assemble a stack of hundreds of libraries in minutes, then get back to focusing on the science.”

For more about open source software from LLNL, visit the web.

---

Source: LLNL