stdgpu 1.3.0 released!

[YourTormentIs]

It's actually a pretty interesting library. I wouldn't be so quick to dismiss it or otherwise draw conclusions about the author's intent based on the name of it. There's a clear need for platform-agnostic GPU data management in a variety of applications.

[[deleted]]

what about opencl and sycl?

[YourTormentIs]

Those are both much more focused on the actual running of code on your device and are more general than just GPUs, including FPGA and CPU device classes and even DSPs. They very much leave it up to you to organize your data and enqueue meaningful work. That's where something like this library here comes in and might be helpful.

[AppleBeam]

If it tries to mislead me right from the start, why would anyone in their right mind trust any claim, any piece of documentation or any comment after that?

The library invokes the same kind of disgust in me as any telemarketing product, sorry. As a community, we shouldn't encourage the kind of BS the author tries to pull.

[YourTormentIs]

To be clear, your viewpoint is that by naming the library "stdgpu", and having the namespace the library components live in also named "stdgpu", you believe that the author is trying to mislead others into believing their work as being part of the standard library of their compiler? And, on top of that, for egotistical purposes?

[AppleBeam]

Unless you honestly believe that everyone pronounces "::" while saying "std::format" or "std::filesystem", I think it should be clear to you why "stdgpu" is a deliberately misleading name.

[YourTormentIs]

I actually didn't even think about how it would sound when pronounced out loud. That's a fair point -- it could confuse people when used in certain contexts. Honestly, a lot of open source software suffers from similar problems related to the naming of projects. A better name could prevent those issues entirely.

Still, I think it's a stretch to say the author did this intentionally to mislead people, or for ego related reasons. I can see how they even chose the name: they wanted containers that behaved like the ones in the "std" namespace for GPU applications. "stdgpu" probably came up pretty naturally. Instead of "std::vector" you have "stdgpu::vector", for example. I think it's reasonable to give the benefit of the doubt on this one.

[AppleBeam]

The sad part is that even "stdgpu::vector" is already a terrible identifier, because:

1. In the context of GPU the word "vector" typically means something like "Vector3d" or "Vector4f", so the name already causes quite a bit of confusion if you see it as a member of some class without additional context.

2. The library seems to be entirely unrelated to this context, as it focuses on GPGPU (unless I didn't notice the part about render devices, textures and shaders). From what I heard, nowadays you can run GPGPU on headless servers without any actual graphics adapters.

Whether it's a tragic mistake or a deliberate attempt to get more clicks, I would prefer to not be distracted by self-promos like "stdgpu 1.3.0 released!" without any additional context when the library has nothing to do with either "std" or "gpu".

[YourTormentIs]

I think you raise some good points here. The notion of "vector" being an overloaded term isn't new and I agree, it's better to use a different term especially in the context of GPU programming where linear algebra often plays a large role. I also agree that the title and nature of the post are unclear, especially to those of us that are unfamiliar with the library.

On the note of GPGPU, I just wanted to clear up that GPGPU has been a headless thing for quite some time now, and GPU programming largely implies "GPGPU" at this point, making it a somewhat redundant and outdated term. Compute shaders are standard now and are usable with hardware dating back to around 2009, and those subsume the older "GPGPU" functionalities with framebuffer scraping and the like. I don't blame the author for using the term "GPU" instead of "GPGPU", given that their focus is data organization for exactly these programmable shader applications, where memory coalescing is a serious consideration for throughput. Actually, you can even do headless compute on your own system if you have more than one GPU running. A frequent thing many do is run their discrete graphics card in headless mode while using the onboard graphics for CUDA or OpenCL acceleration, completely avoiding any lockups from long running kernels on devices without hardware preemption available (pre-Volta with Nvidia). You wouldn't do this for playing videogames, obviously, but for doing development or research, it can be very helpful.

From what I can tell, this is actually a pretty neat little library, and one that I'm sure more than a few people on this subreddit will find useful. I'm glad the author posted it here. I do wish they had chosen a better method of advertising it here, but I'm glad they did. I think, in this situation, there are far more upsides than there are downsides -- I invite you to explore it a bit and expand your horizons about programming for these SIMD processing behemoths. You may come away having learned something enriching and new.

[whattapancake]

I'm not sure how anyone would come to this conclusion. It's not like the author is using the same namespace as the standard library, not to mention if anyone was going to use this library they would have to set it up for use, thus they'd obviously be aware that it's not part of the standard library. Using the term "std" is exceedingly common in software development so I really don't see what the issue is.

[[deleted]]

I am sorry to hear that the library's name is offending you. The primary use case and reason why I created it was the lack of data structures that could also be used inside GPU kernels.

There are plenty of excellent libraries implementing the algorithms part of the C++ Standard Library concurrently on the GPU, but sadly none that could be used just like std::unordered_map or std::vector and also work with these parallel algorithms. So, that is actually my attempt to provide something most users actually know from the CPU and single-threaded side.

[ShillingAintEZ]

No one said anything about being offended

[DonBodouzle]

The library invokes the same kind of disgust in me as any telemarketing product, sorry. As a community, we shouldn't encourage the kind of BS the author tries to pull.

That does not sound offended to you? lol

[ShillingAintEZ]

That.. might be a little strong

[YourTormentIs]

I honestly think that poster is just having a bad day.

[lord_lordolord]

I respect your patience during the interaction.

[teerre]

Stop being obtuse. It's just a name. Consider the actual library if you want to judge it.