Enterprise advanced scale computing – or HPC in the enterprise – is an entity unto itself, situated between (and with characteristics of) conventional enterprise IT, on one side, and traditional HPC at supercomputing centers, on the other.
When these three groups rub against each other, conflict is natural – conflict in outlook, requirements, aspirations and methods. Such is the challenge for the U.S. Department of Energy’s Exascale Computing Project (ECP) as it guides the country’s development of exascale (a billion billion calculations per second) computing. The next frontier in supercomputing, exascale also is being pursued in China, Japan, Russia and the EU, it’s generally regarded as critical to national security, scientific discovery and industrial, economic competitiveness.
The American effort emphasizes “capable exascale,” which the ECP defines as more than a system that can attain an exascale benchmark: “ECP’s work encompasses the development of an entire exascale ecosystem: applications, system software, hardware technologies and architectures, along with critical workforce development.” In short: usability and broad applicability, including adoptability by industrial companies.
That’s where the ECP’s Industry Council (IC) comes in. An external advisory group comprised of managers from 17 major corporations (Lily, Westinghouse, Dreamworks, Exxon Mobil, etc.), it serves as a voice on supercomputing issues that industrial companies care about.
We recently talked with IC Chair Dave Kepczynski, CIO, GE Global Research, General Electric, who discussed the IC’s mission within the ECP’s overall development work. Kepczynski freely states that GE – and many other industrial organizations with insatiable compute-intensive requirements – can’t wait to get their hands on an exascale system, as long as it’s a system designed with compassion for their technical skills, existing applications and workload environments.
Following are excerpted remarks from Kepczynski in which he talks about the exascale technology he and his IC colleagues envision. As does the ECP, he emphasized that the U.S. exascale effort has a broader, more inclusive development perspective than previous government-funded supercomputing projects.
Some of the big projects of the past have been more focused around the hardware technology and programming instruments. What’s evident now is there is an entire key element around product management, around software and integrations and testing…
Two things are at an intersection with the Industry Council, and they’re hardware- and software-related. We want to have a reasonable level of standardized hardware that really drives reusability of the technology architecture. That, I think, is an important piece. It’s already being demonstrated by the ECP because of the number of labs that will then re-use the blueprinted hardware and technology architecture; and not in all cases is it coming from the same hardware vendors or the same hardware make-up. So that’s a good way to demonstrate it.
The other key piece, for us, is industry-friendly software. We’re looking for reusable integration applications and microservices. We spent our last face-to-face Council meeting just on that side of the equation…. It’s more than just the hardware technology, we all recognize that now, we really need to get the entire integrated technology stack ecosystem right… We had a panel of our ISVs (Ansys, Cascade Technology, Altair) that are part of the Council to talk specifically about what everyone is doing next, so we can concentrate effort around reusable integrations, applications and microservices.
So it’s not hardware-led, it’s both hardware and software. Part of the discussion we had is that in the past the hardware kind of led and software lagged. The go-forward plan (hardware alongside software) is more than just an attempt, it’s part of the ECP. That’s why there are ISVs as part of the IC… That’s why these discussions are important for all of us. The sooner we create industry-friendly software the sooner we can shorten…speed to implementation and integration of exascale.
Refactoring Applications for Exascale
We have software and applications internal to the national labs, we have our ISVs, and we have our own internal software and applications. At GE, we have our own internal proprietary (software) that we use on aviation, for purposes of combustion and aero development, and in fact we have even used one or several of them in conjunction with U.S. government DoE national labs’ compute environments.
So all three of those are important here for us to deliver capable exascale. We need to recognize the amount of software development (and code refactoring) that will need to go into taking advantage of this next generation of parallel processing capability – taking advantage of the new technology architecture with interwoven CPUs with GPUs.
We’ve begun work on prioritized software and applications…, there is some early development that is becoming available on pre-exascale technology, and those are opportunities for ISVs and industry partners to begin testing of refactored (code). There are some early templates of the technology architecture, and so you don’t need to be a large company to begin to understand if or when or how you can take advantage of exascale.
Exascale in GE’s Future?
I would say yes, (exascale is in GE’s future). What we have internal to our company, which isn’t much different from many industrial companies, is you have a mix of supercomputing environments… Exascale is definitely on our future roadmap. We don’t want to have this big lag that we’ve had in the past (between HPC technology used in supercomputing centers and HPC used in industry)…. We want the same in order to differentiate and continue our U.S. competitiveness. We want the next levels of technical velocity, improved cycles, higher (compute) performance, higher fidelity at lower cost.
It almost gets you to ask yourself: Over time, with compute capabilities continuing to grow, most companies have already begun…their transition between less physical tests and more computational, experimental methods, heightened leveraging of advanced technologies and HPC.
There used to be many physical tests at very high cost. That doesn’t mean we’re eliminating physical tests. It means we can significantly reduce the number and significantly improve the expected results of our physical tests….
Most industrials today, whether U.S. or global, using computationally advanced applications on the supercomputing side of the equation, are really working on components and subsystems. The question is what’s the limitation? The limitation is the level of computing (available). The crux of the matter is we want more capable compute to leverage.
Today we do a lot of performance analysis and optimization at these part/subsystem levels. But really, we want to do system and environmental computational and virtual validation work at a multi-disciplinary, multi-system level. And that’s where the next level of computational capabilities is going to be able to take us as an industry.
A version of this article first appeared on our sister site EnterpriseTech.