The Path to Streamlined Cross-Architecture Development | oneAPI | Intel Software

The Path to Streamlined Cross-Architecture Development | oneAPI | Intel Software


[MUSIC PLAYING] Hello, and welcome
to Tech Decoded. I’m Henry Gabb, editor
of The Parallel Universe. Today I’m here with Bill
Savage, vice president and general manager of Compute
Performance and Developer Products. Welcome, Bill. Hello, Henry. So Bill, Intel
recently announced the oneAPI initiative. Can you tell us what oneAPI
is and the vision behind it? It’s about architecture, Henry,
both hardware and software. As Intel expands,
the architectures we’re supporting to address the
emerging data-centric workloads for customers, we
needed to architect a software solution that
would simplify the programming of those diverse architectures. So the main vision of oneAPI
was to give a programming abstraction that would
unify and simplify the diverse architectures that
meet customer workload needs. And so in your view, what are
the major aspects of oneAPI? There’s two major aspects– an industry
specification, where we’re specifying a language and a
set of APIs for the industry, as well as a low-level
interface to hardware. And the second part
is an Intel product, the oneAPI product that
implements the compilers for that language, the
libraries for those APIs, but also includes
debuggers, analysis tools, and other related
products and tools that support the one API standard. Now you’ve experienced
and even driven some of the major inflection
points in software, as an example, the move
from serial performance to parallel performance. Can you reflect on
those inflection points? Yeah. Each of those inflection
points that I’ve been involved in and
observed in the industry were motivated by a change
in hardware architecture. For example, the push
for parallel software was motivated by the need
for multicore architectures. Multicore architectures were
needed because we couldn’t continue to scale at frequency. So the reality of
multicore architectures required a software solution. And then another inflection
point in the industry was when GPUs started to
provide compute capabilities in the data center,
a software solution was needed to give access
to the GPU architecture. And a final one
that we’ve observed was the emergence
of deep learning and artificial intelligence. And as that came
to the industry, there needed to be a set
of software that enabled that change in the industry. And oneAPI is along those
journeys, the experience that we’ve had internally
to Intel, as well as our observations of our
competitors in the industry all form together
for us to architect the exact needed solution
for the oneAPI diverse architecture. And so how does
cross-architecture and cross-vendor development
help the developers in the developer community? In two ways. The language that we’ve
selected, Data Parallel C++, lets them program in a common
programming language that can cross these architectures,
as well as crossing vendors. Oftentimes, solutions
in languages, in particular in the case
of CUDA, is vendor-specific, and oneAPI is open,
standard, available for multiple
architectures and vendors. And then the libraries,
as well, helps the developer cross
architectures and vendors with a common
software investment. So the benefit to developers
are lowering their cost in addressing a
much broader market of diverse architectures. And so what differentiates
oneAPI from other approaches? The language is different
than previous language. Our Data Parallel C++ delivers
uncompromised performance by sharing a common source
language that can cross not only architectures but vendors. So we were very diligent to find
a language that can do that. Java delivered
cross-architecture but not performance. OpenCL attempted to
deliver on this promise. We think we’ve found
a language that does. Through explicit expression
of parallel kernels, the compiler can create the
threading, the vectorization, and the other operations
needed to fully exploit the parallelism of
multiple architectures. And then the libraries,
as well, we’re motivated as Intel to give
libraries that actually cross architecture boundaries. Up till this point,
both vendors have been motivated only to
enable a single architecture. And so we’ll have a
full suite of tools, presumably, that will
give complete visibility into the hardware. Is that correct? Largely, yes. That the full suite
of tools– analysis, as well as compilers
and libraries– will give full insight
into the hardware and allow developers
to fully exploit that hardware and
its performance with a shared source
code investment. Well, my favorite part of
the interview is to ask, do you care to make
any bold predictions for the next 5 to 10 years? Bold predictions– well,
I do want to be clear. oneAPI is a phased approach. It’s going to be a
multiyear effort. We’ll introduce our
first beta this year. A product later, we need to work
with partners in the industry. So this is a multiyear
effort with many phases. So if I’m looking
in the future, we have multiple vendors
across the industry, including some of
our competitors, have adopted oneAPI as the
standard for programming in the data center,
and that Intel has its broad reach
of architectures deployed in the industry fully
enabled by that software. Thanks, Bill, for sharing
your insights today. We’re all excited about oneAPI. Thank you, Henry. I’m Henry Gabb
with Tech Decoded. Please visit our website for
more information about oneAPI. [MUSIC PLAYING]

Leave a Reply

Your email address will not be published. Required fields are marked *