Registration debate Welcome to the latest registration debate, where authors discuss technical topics and readers choose the winning arguments. The format is simple: we propose a proposal, the arguments of the proposal will be carried out on Monday and Wednesday, and the arguments against will be carried out on Tuesday and Thursday. Within a week, you can use the polls embedded below to vote for which party and choose whether you are for or against the motion. The final score will be announced on Friday, and the arguments for or against are the most popular.
The motion this week is: A unified, unknowable software environment can be realizedWe discussed a question: Can the industry have a truly open, unified, and agnostic software environment in HPC and AI that can span multiple computing engines?
Our contributors debate today be opposed to The motion is Timothy Prickett Morgan, co-editor of The Next Platform.
Nothing in life is simple, is it? In the broader field of high-performance computing simulation and modeling and machine learning, perhaps one day they will become a unified field, just like quantum mechanics and relativity, there may be a single programming environment that can span all of these. But for now, in the post-Moore’s law world, every transistor is important, every bit of movement and processing is important, every joule of energy is important, and there is nothing inefficient in the hardware and software stack. room.
This means that the programming stack will become complicated. This is an inevitable trade-off between application performance and application portability, and we have seen this in commercial and HPC computing for more than five years.
HPC and AI stores value performance more than anything else-performance is a more important cost of simulation and AI training, which is why we believe that there will be many different languages in use in the foreseeable future, and each language may have many Different compilers have an ever-expanding array of devices.
How many different C compilers do we need? Throughout history, more than 50 different C and C++ compilers have been created, and there may be six to a dozen popular compilers at any given time. We think this will not change. If we can’t get a C compiler that can optimize code for all CPUs, how can we do this in multiple languages, not just CPUs, but also GPUs, FPGAs and custom ASICs?
It is easier in the enterprise than in the HPC and AI markets, because the enterprise values price/performance and code longevity more than raw performance. This is about making money — and keeping as much as possible — not about solving the mysteries of the universe or letting our phones give us convincing answers.
Companies value the compatibility of programmers—whether they can let people build and maintain their code—and also consider the portability of programs—whether they can run it on different hardware and operating systems. Therefore, Java has become popular, and it is not a high-performance language. Sometimes, although they are all known as C++ programmers, hyperscalers and cloud builders choose Java to create analysis stacks or databases.
This will never be the correct answer in HPC, nor in AI. The reality of the 21st century is that everything that can be adjusted must be adjusted and adjusted well, which means having more tools to cover various devices.
This is a good thing, although having a single standard brings all the benefits-the biggest benefit is the elimination of complexity. But this also eliminates competition. Setting competitive standards for everything will promote innovation, it will weed out bad ideas and retain good ones. To be fair, the lack of standards at any layer of the software stack will create islands of incompatibility, and you will pay a heavy price for betting errors when choosing software tools.
It’s easy to get standards for pipes in the IT stack—well, it’s relatively easy—we have seen many successful standards, such as many different peripheral standards (PCI and PCI-Express, now the latter’s CXL coverage) and mutual Even the standards (Ethernet shines, InfiniBand shines too). But applications are not pipes, they are liquids flowing through pipes. Getting people to agree on the formula for the liquid is much more complicated.
Rather than establishing a standard programming environment for HPC and AI, perhaps what we need is cooperation so that we can agree on the pipeline, and then there is a way to switch from one liquid to another as needed, so that AMD’s ROCm environment can be The Nvidia software environment where compatible CUDA code can run locally on Nvidia GPUs is an example; we expect that if Intel’s oneAPI work succeeds, ROCm will also be able to absorb or output SYCL code.
Conversion is always accompanied by performance losses, but if industry leaders work together in this area — and large HPC and AI centers insist on doing so — there should be technology sharing. Think of it as a set of interconnected moats, like Venice, instead of isolated castles that are far away from each other, surrounded by isolated moats.
We want to connect the moat and let the code flow back and forth. ®
Vote below. We will close the voting on Thursday night and announce the final result on Friday. You can follow the progress of the debate here.
