Tools
Explore new features and tools within Intel® products, communities, and platforms
82 Discussions

What Is Next for Accelerated Computing and oneAPI: A Panel Discussion

Nikita_Shiledarbaxi
1 0 1,542

Authors: Nikita Sanjay Shiledarbaxi, Rob Mueller-Albrecht

At the oneAPI DevSummit 2023, industry experts came together to discuss the need for an open community-driven approach to performing accelerated computations on architectures from diverse vendors. Modern computing takes advantage of a wide selection of available hardware accelerators, including CPUs, GPUs, and FPGAs. The oneAPI industry initiative has introduced an open, cross-industry, standards-based, unified, multiarchitecture, multi-vendor programming model. This contrasts with the conventional proprietary approach traditionally seen in the industry for offload acceleration onto GPUs.

The oneAPI DevSummit 2023 panelists stressed the need for such an open and flexible approach to heterogeneous workloads that can be ported easily across different hardware platform configurations without significant performance impact. They covered the processes, developer needs, and challenges we face as we drive towards accomplishing this vision for the future of software development.

This blog will spotlight the key points made during the panel discussion.

About The Panelists

Moderator – James Reinders: Software Architect and Evangelist at Intel Corporation; author/co-author/editor of 10 technical books on parallel programming.

Maria Elli: Data Scientist at Intel Corporation

Felix LeClair: Open Source Developer focused on HPC, SIMD, and SYCL

István Z Reguly: Associate Professor at ITK Pázmány Péter Catholic University

Zhuldyzzhan Sagimbayev: Lead Machine Learning Engineer at Cerebra.ai

Jian Huang: Professor of Computer Science at the University of Tennessee

Hartwig Anzt: Director of Innovative Computing Lab (ICL) at the University of Tennessee; Senior Research Scientist at Karlsruhe Institute of Technology

Eric Nielsen: Senior Research Scientist at NASA Langley Research Center

Mohammad Zubair: Professor of Computer Science at Old Dominion University

A complete recording of the session is available here.

SYCL* and oneAPI aim at helping us in accelerated computing, according to the panel moderator James Reinders. The discussion revolved around what the panelists expect from SYCL and oneAPI for achieving their common goal and the gaps that need to be addressed to successfully drive this open, standard approach into the accelerated computing community.

Performance Portability

Offering portability across architectures from different vendors is important. However, in addition to portability, users want to have only minimal performance impact when executing on different architectures. That is termed as ‘performance portability,’ an advantage offered by SYCL and oneAPI, as per the panelist Hartwig Anzt. Though performance portability is the topmost priority, portability across different types of devices is also a goal of accelerated computing, in the opinion of the panelist Felix LeClair. Consider running your workload on a hierarchy of devices and falling back from a GPU to a CPU implementation. Ideally, you can ship the same code based on a common framework to any other hardware for its execution.

Panelist Mohammad Zubair pointed out that one of the challenges portable frameworks such as SYCL and oneAPI face is how newly added features get exposed at a portable level as accelerators evolve. However, such a challenge is often encountered in large-scale open-source projects and has some interesting solutions, as the panelist Istvan Reguly suggested. For instance, the OpenCL* compiler allows you to insert a CUDA code into a SYCL code. Though at the cost of portability, it lets you get the last few percentages of the performance without shifting the code entirely from the SYCL framework.

Felix also mentioned an important concept of maintainability which helps reduce portability time. Instead of rewriting the code on a new system from a different vendor, you can tweak the core SYCL code a bit and add CUDA pragmas to achieve the last few percentages of the performance on the new machine.

Interoperability As an Advantage

According to Istvan, another strength of SYCL and the oneAPI libraries, particularly crucial for large production applications, is their ability to interoperate with other libraries and languages. Hartwig also highlighted how oneAPI is going in the direction of creating a common interface so that you do not need to restructure your code for calling the vendor-specific oneAPI libraries across diverse architectures.

SYCL And Standard C++: A Co-existence

Hartwig made the point that SYCL being a separate standard evolving together with C++, may prove to be an advantage. It allows SYCL’s evolution to be more agile and introduce new functionalities faster without interfering with the need for stability in the C++ standard at large. Unlike C++, things like parallel constructs and GPU memory management are part of SYCL to allow it to keep up with hardware evolution. For that reason, he foresees SYCL and C++ to remain somewhat independent in the future.

The inheritance of C language properties by C++ has not been without its’ challenges.

The question was raised whether SYCL might get into similar challenges of tracking changes in C and C++ standards and getting tied to specific C++ versions.

However, James pointed out that C++ is facing issues trying to stay aligned with C in its attempt to outgrow the standard C. SYCL does not intend to do any such thing. It provides a C++ compliant extension and is not in competition with C++. It complements the C++ language similarly to OpenMP* and should not inherit those issues.

Interoperability As a Challenge

oneAPI and SYCL form the foundation of many modern applications. However, Interoperability among different abstraction layers is a constant struggle in the industry. We may have two projects intended to work together, but because they use different design frameworks, the best approach to coordination and data synchronization is not obvious. As suggested by Jian Huang, one way to approach this challenge is to stitch together the entire application logic into a common scripting language such as Python*, Julia*, and JavaScript*. This, however, makes the execution flow difficult to translate for someone on the same project who works lower on the software stack.

In addition to being at the center of many modern applications, the framework abstraction oneAPI can serve as a bridge between you as a programmer and the scripting language you use for writing the application code. It can thus add a higher-level entry point for the application, allowing you to use higher-level language such as Python or Matlab* to query lower-level routines.

oneAPI Evolution: A Progressive Effort

Compared to some third-party application programming interfaces, oneAPI gives you an amazing performance gain for certain applications simply by adding a few lines of code or by adding a few oneAPI libraries. According to Maria Elli, the oneAPI ecosystem is constantly evolving, and the community's continuous effort to upstream the changes being made to the oneAPI toolkits will continue to be a future need in the industry.

Portability vs. Performance: A Trade-off

Without a portability layer like SYCL, which can run on all types of architectures, you may have high-performance software that can run only on a specific kind of machine. Adding a portability layer may cost some performance. However, this may well be outweighed by code portability across diverse architectures.

There is a trade-off: You can either have high performance on just one type of device, or you can have high portability at the cost of some performance. Finding the best balance of portability and performance and identifying how to achieve the best mix of both for your project is key. Eric Nielsen pointed out that it needs to be an organizational, team-level, or application-level decision.

Is it best to adopt a performance portability model or to stick to a native programming model? The decision has to be made for each specific use case.

Wrap-up

We hope this blog gave you interesting insights into the future challenges that the software industry faces, along with the role of oneAPI in evolving software development so it can thrive in the age of accelerated computing.

We encourage you to check out the AI, HPC, and Rendering tools in Intel’s oneAPI-powered software portfolio.

Acknowledgment

We would like to thank Chandan Damannagari for his contribution to this blog.

About the Author
Technical Software Product Marketing Engineer, Intel