Sign up for our newsletter and get the latest HPC news and analysis.
Send me information from insideHPC:


Podcast: One Big Debate over OneAPI


 
In this podcast, the Radio Free HPC team looks at Intel’s oneAPI project.

The OneAPI project is a highly ambitious initiative; trying to design a single API to handle CPUs, GPUs, FPGAs, and other types of processors. In the discussion, we look under the hood and see how this might work. One thing working in Intel’s favor is that they’re using data parallel C++, which is highly compatible with  – and which is probably Intel’s target with this new initiative. Henry points out that porting codes is a pain and that no one wants to port to another API if it can possibly be avoided, so he predicts that most customers will not want to use it and if they consider it, before they move any code, they need to be sure that this new API is going to stick around for many years.

Shahin is generally positive on the project. Henry and Dan to have a rare moment of agreement in disputing Shahin’s thoughts about several things! Let’s start with his view that Java has provided portability in exchange for performance – and then improved its performance. Henry and Dan take issue with this, with Henry saying that Java provides little real performance and Dan saying that programs have changed to provide Java performance rather than Java changing to provide performance. Shahin believes that OneAPI is a good thing for the industry and will be successful. Dan believes it’s a good thing for Intel, but has doubts about whether it’s good for the industry. Henry doesn’t see big adoption for the foreseeable future saying, “It has a long way to go and it’s a significant risk.” Dan and Henry end up agreeing and agreeing to disagree with Shahin. Jessi is safely on the fence on this one.

Other highlights:

  • Henry shares a personal story about key fobs and a very troubling problem he found with his latest rental car. It has everything, thrills, chills and a shocking conclusion.
  • Jessi:  The Department of Defense has built a supercomputer in a shipping container, for sending to wherever its computation is needed. The supercomputer itself is designed to work on AI-related problems, and falls under the classification of “AI on the edge,” where data is processed in the same location it is collected. While it’s not news, it’s news to Jessi and it’s cool, so it’s her catch of the week.
  • Shahin:  Tells the story of a reporter renting a shared car service, which is unlocked by a cell phone. The reporter ventures out into the hinterlands a little bit and finds that she can’t get the car to work anymore. Why? Because there wasn’t enough cell phone coverage to properly start the car – meaning that the reporter had to wait (and wait) for a person to be sent out to physically interact with the car and get it going again. Yikes – think out your products, people, ok?
  • Henry:  Hackers made a home for themselves inside Citrix for five months, siphoning off personal and financial information. Yikes again. The company had to be alerted by the FBI to the hack and, assumedly, their internal tools didn’t pick up the penetration. That’s a long time to be exploited!
  • Dan:  McAfee researchers show that just a few strips of tape on a road sign can prompt a Tesla car to accelerate by an astounding 50 miles per hour over the posted speed limit on that sign. According to Dan, this is a bad thing.

Download the MP3 * Follow us on Twitter Subscribe on Spotify Subscribe on Google Play Subscribe on iTunes RSS Feed 

Sign up for the insideHPC Newsletter

Comments

  1. Looks like the main point of this article is about seeing oneAPI adoption in the community.
    You are right that people do not want to move yet another API unless they know it will stick around. Good news that this is based on SYCL which has been around for a while now. And as a Community Manager I do see developers adoption it , since they want to be able to run the code on multiple platforms. Look at the projects developers are working on with oneAPI as we speak.

    Hope to talk to you sometime.

    https://devmesh.intel.com/projects?sort=best&lat=37.3229978&lng=-122.0321823&query=oneapi

  2. Michael Wolfe says:

    Intel has a history of developing or acquiring a number of parallel programming models, and abandoning them when they don’t get enough adoption. Anyone remember Intel Ct? Intel Cluster OpenMP? Anyone recall Intel Array Building Blocks? What about Intel Cilk Plus? So many that Intel created a banner brand to cover several of them (Intel Parallel Building Blocks = ArBB + Cilk Plus + TBB). Of all these, Threading Building Blocks alone survives. What makes you think OneAPI will beat those odds? Having a single language that allows you to write programs for CPU and GPU and other accelerators is good, but tobe great it must deliver performance from a single program across all those targets.

    • Michael: Not just that, but if any API only targets one vendor of hardware, it is doomed for low adoption. I have no desire to learn OneAPI if there is no way to compile to AMD/NVIDIA.
      One can say the same thing about CUDA and ROCm, which is why I chose OpenACC to accelerate our codes. Although cross-vendor implementations are not quite there yet, they are in active development (same for OpenMP-offload) and have a MUCH better chance of being around in 10 years.

    • And @Michael to your point, we are seeing Broad community adoption, hence I do not see us dropping it like the other libraries.

Resource Links: