4 ms·

Intel CTO wants developers to build once, run on any GPU

15 points by CrankyBear 4y ago

johnklos 4y ago
While I agree with the sentiment, the analogy is quite flawed. Build once, run on any GPU is an excellent idea. We've all suffered for too long from the artificial limitings of GPU development and market manipulation at the hands of wish-I-could-be-a-monopoly NVIDIA. The same way we can take any halfway decent software project and compile it on any architecture, whether it's Alpha, PowerPC, ARM or amd64, we need to have GPU code that can just run wherever, whether it's on AMD, NVIDIA, Intel, Apple ARM, or on general purpose CPUs when GPUs aren't available. But what we DON'T need is another Java - we don't need broken backwards compatibility, stewardship by a backwards, money hungry corporation, tons of overhead, security nightmares. We need open languages that can target any common platform, thank you, and if that's truly what Intel wants, too, then I'm all for it. Just not like Java, thank you.
waynecochran 4y ago
When writing GPU code I often optimize/ tailor the algorithm to the details of the architecture. Trying to write generic GPU code that is performant across multiple platforms is ugly, painful and produces larger and less maintainable code. One actually chooses different algorithms based on the architecture.
- moab 4y ago
  That sounds awful and a big reason why I think GPUs will go the way of the dinosaur in the near future.
  - skavi 4y ago
    Nothing about GPUs technically forces you to code for specific architectures. It’s really no different than optimizing your code for a specific CPU.
    - moab 4y ago
      I think it's quite different. For GPUs these archiecture-specific optimizations / primitives make orders of magnitude difference (and also change from version to version). On the other hand, multicore code I wrote ~8 years ago in TBB or Cilk is still extremely fast compared to hand-optimized code customized for current CPU architectures. To summarize my gripe, it's is that the abstractions on GPUs seem broken, and we still don't have a good model for how to write high performance GPU code that just works and keeps getting faster as GPUs get faster.
adrian_b 4y ago
The interesting information here is that Intel has developed an open-source tool, SYCLomatic, which can be used to migrate existing CUDA codebases to SYCL, the Khronos standard GPU programming language promoted by Intel. https://github.com/oneapi-src/SYCLomatic https://github.com/oneapi-src/SYCLomatic
- arcanus 4y ago
  SYCL also nominally tries to support AMD GPUs. In my experience, the runtime is poorly optimized and performance is low.

15 points by CrankyBear 4y ago

While I agree with the sentiment, the analogy is quite flawed. Build once, run on any GPU is an excellent idea. We've all suffered for too long from the artificial limitings of GPU development and market manipulation at the hands of wish-I-could-be-a-monopoly NVIDIA. The same way we can take any halfway decent software project and compile it on any architecture, whether it's Alpha, PowerPC, ARM or amd64, we need to have GPU code that can just run wherever, whether it's on AMD, NVIDIA, Intel, Apple ARM, or on general purpose CPUs when GPUs aren't available. But what we DON'T need is another Java - we don't need broken backwards compatibility, stewardship by a backwards, money hungry corporation, tons of overhead, security nightmares. We need open languages that can target any common platform, thank you, and if that's truly what Intel wants, too, then I'm all for it. Just not like Java, thank you.

waynecochran 4y ago

When writing GPU code I often optimize/ tailor the algorithm to the details of the architecture. Trying to write generic GPU code that is performant across multiple platforms is ugly, painful and produces larger and less maintainable code. One actually chooses different algorithms based on the architecture.

moab 4y ago
That sounds awful and a big reason why I think GPUs will go the way of the dinosaur in the near future.
- skavi 4y ago
  Nothing about GPUs technically forces you to code for specific architectures. It’s really no different than optimizing your code for a specific CPU.
  - moab 4y ago
    I think it's quite different. For GPUs these archiecture-specific optimizations / primitives make orders of magnitude difference (and also change from version to version). On the other hand, multicore code I wrote ~8 years ago in TBB or Cilk is still extremely fast compared to hand-optimized code customized for current CPU architectures. To summarize my gripe, it's is that the abstractions on GPUs seem broken, and we still don't have a good model for how to write high performance GPU code that just works and keeps getting faster as GPUs get faster.

adrian_b 4y ago

The interesting information here is that Intel has developed an open-source tool, SYCLomatic, which can be used to migrate existing CUDA codebases to SYCL, the Khronos standard GPU programming language promoted by Intel. https://github.com/oneapi-src/SYCLomatic https://github.com/oneapi-src/SYCLomatic

arcanus 4y ago
SYCL also nominally tries to support AMD GPUs. In my experience, the runtime is poorly optimized and performance is low.