Hacker News Reader

Comment by 01100011 | Hacker News Reader

Curious how this stacks up against CUDA(from a programming perspective, almost guarantee CUDA is faster). Does this provide a way to manage/copy memory back and forth from the GPU? Or is it just allowing you to compile some code for the GCN and the rest is up to you?

View on HN

OpenMP 4.5 provides the #pragma target data, target enter data, target exit data, and target update constructs to provide for the memory-management to-and-from the GPU.

omp_target_alloc, omp_target_memcpy, omp_target-associate_ptr provide some other utility functions that you'd expect for these use cases. omp_target_memcpy can copy from host-to-device, device-to-host, or even device-to-device.

This appears to be a GCN backend intended for use with OpenMP and friends, so not really comparable to cuda (more comparable maybe to the llvm nvptx backend).

Why CUDA is faster than OpenCL?

More work put into implementation, better (more optimized) libraries, some additional functionality that lets you do things faster in some circumstances. Cuda doesn't have to care about anything but nvidia gpus, opencl needs to run on anything.

It's not faster from what I've heard. It just has more libraries around it.

It used to be on par on nv hardware. Then nvidia just stopped improving their OpenCL backend.

Otherwise assuming no fancy features are used they are identical in their programming model.

AFAIK the part of identical programming models isn’t the case anymore since Volta, because Volta and Turing have now progression guarantees when you have intra-warp divergence due to the presence of unique program counters for each thread.

Before that, intro-warp divergence combined with badly placed synchronization operations could result in hard hangs.

I don't think this makes a different in terms of raw low level performance, but it might have an impact in terms of implementation algorithms that require synchronization?

Reply on news.ycombinator.com