Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Even Easier Introduction to CUDA

devblogs.nvidia.com

Post reply on HN
Print view View original

51–60 of 60 posts

Re: An Even Easier Introduction to CUDA

#51

Post by rayuela »

joe_the_user wrote: post #47
jupiter90000 wrote: post #27

Does anyone familiar with the state of GPU programming think OpenCL will eventually 'win' over CUDA? Although CUDA has more adoption, I don't like the idea of using it and being locked into a specific vendor. Of course nVidia is only supporting outdated versions of OpenCL for now. Am I a fool for hoping OpenCL eventually becomes the standard?

I've been evaluating Cuda and OpenCL while trying to produce some target independent code. My impression is that while Cuda might not win, OpenCL will almost certainly lose. OpenCL seems to be a monster compromise interface which takes into account all the architectures of the members of a large consortium. It's the sort-of designed-by-committee api that a developer has to fight against to accomplish anything. Natura…

Hadn't heard of this before. This is pretty cool. Does this project have official AMD support?

Re: An Even Easier Introduction to CUDA

#52

Post by se6 »

jupiter90000 wrote: post #27

Does anyone familiar with the state of GPU programming think OpenCL will eventually 'win' over CUDA? Although CUDA has more adoption, I don't like the idea of using it and being locked into a specific vendor. Of course nVidia is only supporting outdated versions of OpenCL for now. Am I a fool for hoping OpenCL eventually becomes the standard?

In 2013 we started GPU programming at the company I work for. We carefully evaluated CUDA and OpenCL and decided to go for OpenCL because it was a standard and we could chose between 2 vendors of GPU. I can tell you that in 2017 we do not regret our choice. It is great to be able to run our code on both AMD and NVidia GPUs, and to offer our customers to choose whichever GPU vendor they prefer.

Many people criticise OpenCL because when you come from C++ it seems a lot of work. It is true that OpenCL has an API influenced by OpenGL and is verbose. However it is not difficult to write a small framework specific to your needs and domain to factorise much of this verbosity.

NVidia does everything it can to hide the fact that their devices support OpenCL. People thinks that only ancients versions of OpenCL run on NVidia devices. That is not true: 1.2 is not ancient is still as of today the main version of OpenCL used. OpenCL 1.2 is fully supported and NVidia quietly say to its large customers who refuse to use CUDA, that they will starting to support soon some OpenCL 2.0 features.

To answer your question, I am not sure either will win, but they will both exist for a long time.

Re: An Even Easier Introduction to CUDA

#53

Post by jupiter90000 »

se6 wrote: post #52
jupiter90000 wrote: post #27

Does anyone familiar with the state of GPU programming think OpenCL will eventually 'win' over CUDA? Although CUDA has more adoption, I don't like the idea of using it and being locked into a specific vendor. Of course nVidia is only supporting outdated versions of OpenCL for now. Am I a fool for hoping OpenCL eventually becomes the standard?

In 2013 we started GPU programming at the company I work for. We carefully evaluated CUDA and OpenCL and decided to go for OpenCL because it was a standard and we could chose between 2 vendors of GPU. I can tell you that in 2017 we do not regret our choice. It is great to be able to run our code on both AMD and NVidia GPUs, and to offer our customers to choose whichever GPU vendor they prefer. Many people criticise O…

Thank you, this is very helpful information I was hoping to hear.

Re: An Even Easier Introduction to CUDA

#54

Post by joe_the_user »

rayuela wrote: post #51
joe_the_user wrote: post #47

Earlier quoted context omitted.

I've been evaluating Cuda and OpenCL while trying to produce some target independent code. My impression is that while Cuda might not win, OpenCL will almost certainly lose. OpenCL seems to be a monster compromise interface which takes into account all the architectures of the members of a large consortium. It's the sort-of designed-by-committee api that a developer has to fight against to accomplish anything. Natura…

Hadn't heard of this before. This is pretty cool. Does this project have official AMD support?

What I remember from this being on hn months ago is that is this an official AMD project aiming to compete with nVidia.

Re: An Even Easier Introduction to CUDA

#55

Post by chalana »

ktta wrote: post #12
natch wrote: post #6

This is great. But it seems like many almost every great tutorial has a step zero that is left out. In this case, for me at least, what is missing is: What's a good guide to choosing or building a CUDA system? Preferably a Linux non-laptop. Mostly for playing around with something that offers a bit more power than my day to day (very non-CUDA capable) laptop. Anyone have suggestions? I think there might be an EC2 sol…

If you are really interested, and willing to spend the time, you can get utterly fabulous perf/$ You can google the specifics, but you can build a powerful and stable system for about 300-400 dollars (a WHOLE system, including a CUDA compatible GPU, not just the GPU) ALL of the following parts can be purchased from ebay(The minimums are taken from actual lists I've taken down while writing this post. There might be s…

Wow Thanks so much!

Re: An Even Easier Introduction to CUDA

#56

Post by doosra »

jlebar wrote: post #45
jupiter90000 wrote: post #27

Does anyone familiar with the state of GPU programming think OpenCL will eventually 'win' over CUDA? Although CUDA has more adoption, I don't like the idea of using it and being locked into a specific vendor. Of course nVidia is only supporting outdated versions of OpenCL for now. Am I a fool for hoping OpenCL eventually becomes the standard?

Honestly for those of us in machine learning, I think something like XLA will likely win over both paradigms. (Disclaimer, I work on XLA.) https://www.tensorflow.org/versions/master/experimental/xla/ XLA much more closely matches what you want for ML than CUDA/opencl. Which isn't a surprise; it was designed specifically for ML. Kernel launches are expensive, so any fast CUDA system has to let you compose computations…

Justin, XLA sounds interesting. Do you assume you always have CUDA sources for ML operations in XLA? I was under the impression that closed-source libraries like cuDNN were used.

Is it possible to accurately evaluate the profitability of fusing two kernels in CUDA (effects of increased register pressure; shared memory)? On the other hand, the generic kernel and its launch parameters were probably hand tuned for performance.

Re: An Even Easier Introduction to CUDA

#57

Post by jlebar »

doosra wrote: post #56
jlebar wrote: post #45

Earlier quoted context omitted.

Honestly for those of us in machine learning, I think something like XLA will likely win over both paradigms. (Disclaimer, I work on XLA.) https://www.tensorflow.org/versions/master/experimental/xla/ XLA much more closely matches what you want for ML than CUDA/opencl. Which isn't a surprise; it was designed specifically for ML. Kernel launches are expensive, so any fast CUDA system has to let you compose computations…

Justin, XLA sounds interesting. Do you assume you always have CUDA sources for ML operations in XLA? I was under the impression that closed-source libraries like cuDNN were used. Is it possible to accurately evaluate the profitability of fusing two kernels in CUDA (effects of increased register pressure; shared memory)? On the other hand, the generic kernel and its launch parameters were probably hand tuned for perfo…

> Do you assume you always have CUDA sources for ML operations in XLA? I was under the impression that closed-source libraries like cuDNN were used.

Yes, XLA calls into cudnn and cublas. It's not a fundamental architectural thing, though; those are just the fastest matmul etc. kernels we currently have access to.

> Is it possible to accurately evaluate the profitability of fusing two kernels in CUDA (effects of increased register pressure; shared memory)?

For a human, yes, sure, just time both options. The system doesn't currently do this in an automated fashion, though. In a fashion similar to a CPU compiler's inliner, it has heuristics and makes its best guess. In general fusion is very profitable.

> On the other hand, the generic kernel and its launch parameters were probably hand tuned for performance.

Yes, and this is one of ways that XLA can lose to (say) vanilla TensorFlow today. But it's just a matter of tuning; the system is very young.

Re: An Even Easier Introduction to CUDA

#58

Post by jlebar »

disposablename wrote: post #46
jlebar wrote: post #45

Earlier quoted context omitted.

Honestly for those of us in machine learning, I think something like XLA will likely win over both paradigms. (Disclaimer, I work on XLA.) https://www.tensorflow.org/versions/master/experimental/xla/ XLA much more closely matches what you want for ML than CUDA/opencl. Which isn't a surprise; it was designed specifically for ML. Kernel launches are expensive, so any fast CUDA system has to let you compose computations…

Why no AMD GPU support?

Why no AMD GPU support?

I think it just reflects the team's internal priorities. Patches are welcome; we want people to use this system.

It wouldn't even be tremendously hard. The XLA IR --> LLVM IR backend is relatively simple, and LLVM already has support for compiling to AMD GPUs. You'd have to split out the nvidia-isms in the generated IR. I think the biggest challenge would just be one of software engineering, namely figuring out a way to specialize the GPU backend for each of the two architectures while allowing it to share code in general.

Re: An Even Easier Introduction to CUDA

#59

Post by nl »

paulmd wrote: post #25
chuckledog wrote: post #24

Earlier quoted context omitted.

Thanks for the great comment. You should write all this up somewhere, it sounds like a lot of hard-earned wisdom!

Thanks for the comment, I really should and I will try to do it sometime before it all falls out of my head any further. I miss doing it, I've just been burned out on trying to unsnarl legacy outsourced Java code for the past 2 years. Like I said, I was actually really jazzed about trying to implement another model in GPU. This model basically consumed zero SRAM, I think I could easily extend it to a fine-grained tem…

This is excellent. You should put your contact details in your profile.

We do disease (and other) predictive modeling and I'm looking for people interested in the field...

Edit: my contact details are in my profile. My group funds and does engineering for work like https://arxiv.org/abs/1609.08283

Re: An Even Easier Introduction to CUDA

#60

Post by joe_the_user »

joe_the_user wrote: post #54
rayuela wrote: post #51

Earlier quoted context omitted.

Hadn't heard of this before. This is pretty cool. Does this project have official AMD support?

What I remember from this being on hn months ago is that is this an official AMD project aiming to compete with nVidia.

See https://www.phoronix.com/scan.php?page=news_item&px=AMD-GPUO... I think...
Post reply on HN