top | item 34846388

(no title)

ggreg84 | 3 years ago

> OpenCL based machine learning libraries, no?

Have you used OpenCL and CUDA C++ ?

CUDA C++ is single-source easy to use, has good tools, has a lots of libraries you can build your new library on top (empowered by generic libraries, it can use all pre-existing C++ libraries), ...

OpenCL... is not single-source, not easy to use, does not have good tools, does not have good libraries that you can reuse (does not have generics), ...

AI is like a F1 race, you can either go race with a F1 car (CUDA C++), or don't go at all. Trying to go with the horsecar OpenCL is, is a waste of time and money. Every other AI startup is going to loop you a million times.

> Nvidia deliberately undermined that at every turn, and pushed a proprietary solution, hard.

Undermined who at what? Nobody was interested in OpenCL succeeding: not Intel, not AMD, not Apple. All these companies pushed and continue to push for their own proprietary incompatible ecosystems to try to create a platform like NVIDIA has with CUDA. Intel pushes for OneAPI which is Intel only, AMD pushes for their CUDA clone, and Apple pushes for Metal.

Its easy to create a new standard. You and me can get together, write something on a napkin, call it a standard, and we are done. We could go around telling people that it's going to be "The Future", like it happened with OpenCL, but that doesn't mean anyone will actually ship something that's usable. It is particularly easy to create a Khronos "standard", of which there are 200, and of which _none_ standardizes standard practice: create the standard first, try to see if it solves the problem later. Claiming that you are entitled to NVIDIA implementing them all, is... well... just that... pure entitlement.

From all vendors, ironically, it actually seems that the only vendor working on a portable way to program GPUs is NVIDIA itself, since they have sent a bunch of people regularly to the ISO Fortran and ISO C++ standard committees to extend these languages to allow portable code to run on GPUs without changes. In contrast to OpenCL, ISO Fortran and ISO C++ are actual international standards.

I think Fortran supports this since 2018 standard, and C++ since 2017. Ironically, NVIDIA is the only vendor that actually ships this and has for years. The NVIDIA fortran and c++ compilers can run these languages on their GPUs. Intel and AMD will talk about how "portable and cross-vendor" OneAPI and ROCm are, yet their Fortran and C++ implementations still, 5 years later, can't actually use their GPUs. The reason is simple, AMD and Intel don't care / believe / want a portable programming model for GPUs. They want their own closed platform. Unfortunately, since they are at a disadvantage, they need their closed platforms to be able to run on NVIDIA GPUs because otherwise nobody would use them, but that doesn't mean that their platforms are portable or open, and they don't care about code using their platform being able to run well on NVIDIA GPUs since that would be counter productive. So in practice, people still need to use CUDA C++ to target NVIDIA GPUs.

Anyways, OpenCL didn't failed "because of NVIDIA". It failed because it is a bad standard, it was a bad standard when it was created (it was significantly worse than the standard practice back then, hence why nobody wanted to use it in practice), and it turns out no vendor is actually interested in it, so it is a worthless standard.

discuss

order

ClumsyPilot|3 years ago

> NVIDIA itself, since they have sent a bunch of people regularly to the ISO Fortran and ISO C++ standard committees to extend these languages to allow portable code to run on GPUs without changes.

Could you probide more details? I could only find C++ AMP by Microsoft

> Claiming that you are entitled to NVIDIA implementing them all, is... well... just that... pure entitlement.

It is? What happened to 'Customer is always right?'

pjmlp|3 years ago

Once on a Khronos promoted session someone asked about Fortran support roadmap for OpenCL, everyone was clueless that was really a thing the scientific community would cared about, and ended up with "if you care about this kind of stuff please come talk to us".

Meanwhile CUDA is having Fortran support for ages.

zozbot234|3 years ago

The intended C++ equivalent for OpenCL is SYCL, which in practice is still under development.

pjmlp|3 years ago

And since Intel acquired CodePlay, it is pretty much an Intel thing now.