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

CUDA Ontology

jamesakl.com

Post reply on HN
Print view View original

21–30 of 44 posts

Re: CUDA Ontology

#21

Post by embedding-shape »

alecco wrote: post #19
w-m wrote: post #5

This is a good resource. But for the computer vision and machine learning practitioner most of the fun can start where this article ends. nvcc from the CUDA toolkit has a compatibility range with the underlying host compilers like gcc. If you install a newer CUDA toolkit on an older machine, likely you'll need to upgrade your compiler toolchain as well, and fix the paths. While orchestration in many (research) projec…

> nvcc from the CUDA toolkit has a compatibility range with the underlying host compilers like gcc. If you install a newer CUDA toolkit on an older machine, likely you'll need to upgrade your compiler toolchain as well, and fix the paths. Conversely, nvcc often stops working with major upgrades of gcc/clang. Fun times, indeed. This is why a lot of people just use NVIDIA's containers even for local solo dev. It's a ha…

> This is why a lot of people just use NVIDIA's containers even for local solo dev. It's a hassle to set up initially (docker/podman hell) but all the tools are there and they work fine.

Yeah, which I feel like is fine for one project, or one-offs, but once you've accumulated projects, having individual 30GB images for each of them quickly adds up.

I found that most of my issues went away as I started migrating everything to `ux` for the python stuff, and nix for everything system related. Now I can finally go back to a 1 year old ML project, and be sure it'll run like before, and projects share a bit more data.

Re: CUDA Ontology

#23

Post by coffeeaddict1 »

I wish GPU vendors would stick to a standard terminology, at least for common parts. It's really confusing having to deal with warps vs wavefronts vs simd groups, thread block vs workgroup, streaming multiprocessor vs compute unit vs execution unit, etc...

Re: CUDA Ontology

#25

Post by jcelerier »

alecco wrote: post #19
w-m wrote: post #5

This is a good resource. But for the computer vision and machine learning practitioner most of the fun can start where this article ends. nvcc from the CUDA toolkit has a compatibility range with the underlying host compilers like gcc. If you install a newer CUDA toolkit on an older machine, likely you'll need to upgrade your compiler toolchain as well, and fix the paths. While orchestration in many (research) projec…

> nvcc from the CUDA toolkit has a compatibility range with the underlying host compilers like gcc. If you install a newer CUDA toolkit on an older machine, likely you'll need to upgrade your compiler toolchain as well, and fix the paths. Conversely, nvcc often stops working with major upgrades of gcc/clang. Fun times, indeed. This is why a lot of people just use NVIDIA's containers even for local solo dev. It's a ha…

Yep, right now nvidia libs are broken with clang-21 and recent glibc due to stuff like rsqrt() having throw() in the declaration and not in the definition

Re: CUDA Ontology

#27

Post by dahart »

This article has good info, but is the overloading premise slightly contrived? Maybe I don’t talk to enough CUDA beginners. I work with CUDA a lot but I’m not exactly a CUDA expert, and from my perspective, in practice there are default assumptions one can safely make for the base terms, and people do qualify the alternatives almost always. For example, if someone says “CUDA version”, they always mean the toolkit, and never mean compute capability, runtime, or language. The term “driver” when used without qualification always means the display driver, and never means the driver API, there really is no overload there.

Re: CUDA Ontology

#29

Post by einpoklum »

> CUDA Runtime: The runtime library (libcudart) that applications link against.

That library is actually a rather poor idea. If you're writing a CUDA application, I strongly recommend avoiding the "runtime API". It provides partial access to the actual CUDA driver and its API, which is 'simpler' in the sense that you don't explicitly create "contexts", but:

* It hides or limits a lot of the functionality.

* Its actual behavior vis-a-vis contexts is not at all simple and is likely to make your life more difficult down the road.

* It's not some clean interface that's much more convenient to use.

So, either go with the driver, or consider my CUDA API wrappers library [1], which _does_ offer a clean, unified, modern (well, C++11'ish) RAII/CADRe interface. And it covers much more than the runtime API, to boot: JIT compilation of CUDA (nvrtc) and PTX (nvptx_compiler), profiling (nvtx), etc.

> Driver API ... provides direct access to GPU functionality.

Well, I wouldn't go that far, it's not that direct. Let's call it: "Less indirect"...

[1] : https://github.com/eyalroz/cuda-api-wrappers/

Re: CUDA Ontology

#30

Post by einpoklum »

dahart wrote: post #27

This article has good info, but is the overloading premise slightly contrived? Maybe I don’t talk to enough CUDA beginners. I work with CUDA a lot but I’m not exactly a CUDA expert, and from my perspective, in practice there are default assumptions one can safely make for the base terms, and people do qualify the alternatives almost always. For example, if someone says “CUDA version”, they always mean the toolkit, an…

I actually find it is pretty easy to get confused between the different kinds of versions. For example:

"The CUDA "driver version" looks like the CUDA runtime version - so what's the difference?" https://stackoverflow.com/q/40589814/1593077

or consider the version you get when you run nvidia-smi, versus the version you get when you run nvcc --version. Those are very different numbers...

The compatibility between different versions of the driver and the toolkit is also a cause for some headaches in my experience.

Post reply on HN