Hello World on the GPU (2019) • Hacker News Board

Re: Hello World on the GPU (2019)

#41

Post by SubjectToChange » Fri, Nov 17, 2023, 10:11 AM UTC

pjmlp wrote: post #40

SubjectToChange wrote: post #39

Earlier quoted context omitted.

This is one area where I imagine C++ wannabe replacements like Rust having a very hard time taking over. I 100% agree. Although I have a keen interest in Rust I can’t see it offering any unique value to the GPGPU or HPC space. Meanwhile C++ is gaining all sorts of support for HPC. For instance the parallel stl algorithms, mdspan, std::simd, std::blas, executors (eventually), etc. Not to mention all of the development…

There is always the argument that it can help reduce the errors produced due to memory corruption. However industry standards matter more.

HPC researchers already employ some techniques to detect memory corruption, hardware flaws, floating point errors, and so on. Maybe Rust could meaningfully reduce memory errors, but if it comes at the cost of bounds checking (or any other meaningful runtime overhead) they will have absolutely zero interest.

Re: Hello World on the GPU (2019)

#42

Post by pjmlp » Fri, Nov 17, 2023, 10:37 AM UTC

SubjectToChange wrote: post #41

pjmlp wrote: post #40

Earlier quoted context omitted.

There is always the argument that it can help reduce the errors produced due to memory corruption. However industry standards matter more.

HPC researchers already employ some techniques to detect memory corruption, hardware flaws, floating point errors, and so on. Maybe Rust could meaningfully reduce memory errors, but if it comes at the cost of bounds checking (or any other meaningful runtime overhead) they will have absolutely zero interest.

Chapel and Julia ongoing efforts proves otherwise, and I can tell from CERN days, not everyone uses those tools.

In any case, that means those languages are much better positioned than Rust in such ecosystem.

Re: Hello World on the GPU (2019)

#43

Post by JonChesterfield » Fri, Nov 17, 2023, 11:06 AM UTC

pjmlp wrote: post #34

JonChesterfield wrote: post #29

Earlier quoted context omitted.

C++20 would be news to me. Do you have a reference? The closest I can find is https://github.com/NVIDIA/cccl which seems to be atomic and bits of algorithm. E.g. can you point to unordered_map that works on the target? I think some pieces of libc++ work but don't know of any testing or documentation effort to track what parts, nor of any explicit handling in the source tree.

Yes, it is right there on the documentation. https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.... Existing restrictions, https://docs.nvidia.com/cuda/cuda-c-programming-guide/index....

Well, the docs say C++ support. There's a reference to and a lot of limitations on what you can do with lambda. I don't see supporting evidence that the rest of libc++ exists. I think what they mean is some syntax from C++20 is implemented, but the C++ library is not.

By "run C on the GPU" I'm thinking of taking programs and compiling them for the GPU. The lua interpreter, sqlite, stuff like that. I'm personally interested in running llvm on one. Not taking existing code, deleting almost all uses of libc or libc++ from it, then strategically annotating it with host/device/global noise and partitioning it into host and target programs with explicit data transfer.

That is, I don't consider "you can port it to cuda with some modern C++ syntax" to be "you can run C++", what with them being different languages and all. So it doesn't look like Nvidia have beaten us to shipping this yet.

Thank you for the reference.

Edit: a better link might be https://nvidia.github.io/libcudacxx/standard_api.html which shows an effort to port libc++, but it's early days for it. No STL data structures in there.

Re: Hello World on the GPU (2019)

#44

Post by imtringued » Sat, Nov 18, 2023, 6:00 PM UTC

dragontamer wrote: post #24

zorgmonkey wrote: post #22

Earlier quoted context omitted.

The author didn't say it, but I'm pretty sure for-loop was meant to be pseudocode to help the reader understand what it does and not the actual implementation.

I'm pretty sure this whole post is a shitpost. A well written joke, and one I enjoyed. But a shitpost nonetheless. Upon closer inspection, the glyphs are each rendered onto the framebuffer sequentially... one-at-a-time. IE: NOT in an embarrassingly parallel manner. So the joke is starting to fall apart as you look closely. But those kinds of details don't matter. The post is written well enough to be a good joke but…

The rasterizer doesn't even do any rasterization. It just blends the already rasterized glyphs onto the screen.

Honestly it sounds like AI. This is a website in the shape/memory of a blogpost, not an actual blogpost.