GE Healthcare is pushing the envelope on driving digital transformation at healthcare.
Over the years we have seen an approximately 5x increase in the number of applications
and products that are being developed on the platform and integrated into the GE Healthcare
ecosystem.
As we look at the heath care space as we talked to customers about the difficulties that they're
having with accelerating their digital journey, we found that the healthcare IT space is actually
quite fragmented.
We have customers from small community hospitals at remote sites to really large IDNs and even
government and nationwide healthcare ecosystems that have access to private data centers and
want to use the private and public cloud.
So GE, when we build our solutions both internally as well as with partners and third-party vendors,
they can be run and deployed across this gamut of this heterogeneous IT space.
We need to make sure they have the right speed and the right latencies because sometimes
there's patients whose lives really depend on the speed of this technology.
There are also things like accuracy, - even the power consumption.
And so, designing to these specs means that all our solutions have to operate across a
variety of very heterogeneous compute resources both for clinical needs as well as IT space.
With oneAPI, you can now develop these solutions once but then actually deploy them with very
minimal rework on this very heterogeneous compute fabric with many different computer
architectures.
That's really powerful and that can really be a game changer for us.
It's a very strong statement of portability of oneAPI when exactly the same code with
just different target being compiled for - can run on Intel CPU, Intel GPU as well as GPU
from other vendors.
We see that it's definitely a major advantage of oneAPI.
Another interesting use case for oneAPI specifically for one of the libraries called oneDNN is
really an ability to program fixed function hardware that is really dedicated to accelerate
convolutional operation for AI and deep learning inferencing and training.
We were quite excited learning how to port cuDNN code to oneDNN and it turned out to
be relatively straightforward as well.
Once we ported our code from cuDNN to oneDNN, we can run it on Intel GPUs but we also can
run it back on Nvidia GPUs with virtually the same performance as native cuDNN implementation.
So from our standpoint to have this oneDNN tool is crucial to actually enable portability
in programming those fixed function hardware functions in the GPU that we believe will
keep growing to address the need to accelerate AI and deep learning inferencing.
We see oneAPI as potentially becoming a de facto industry standard to program heterogeneous
compute systems.
And we believe that using oneAPI actually provides us with ability to port our code
across multiple architectures and even multiple vendors - saving potentially millions of dollars
in configuration cost as well as many, many years of engineering effort that we would
have to invest if we'll have to completely rewrite this code from one programming model
to another.