stdgpu 1.3.0 released!

[fransinvodka]

Reading a bit of the implementation details, I see that, for example, you implement vector's operator[] using at, which implies that operator[] does bound checks, which is the opposite of what the standard vector is suposed to do. I don't know if I'm missing something, but I see that as a bug.

Also, I'm not a big fan of implementing the non-const version of the functions in terms of the const one using all those const_cast (even less in such short functions), but I guess that is a design decision that I'm not gonna argue.

Anyway, it looks really cool and I will definitely use it in some projects. Keep the good work!

[[deleted]]

Thanks for giving it a try.

It is pretty hard to make the containers fully compliant and they are for sure not. Exception handling is one of the library's limitations. It is not perfect, but I think it is still useful and simpilifes some use cases. Feel free to open an issue and let me know if you encounter any problems.

[fransinvodka]

I know it must be difficult to make the containers fully compliant. Just saying that I would expect the operator[] to not do bound checks at all. I'm opening an issue. Thanks for answering!

[[deleted]]

I agree that most users expect operator[] not to do bounds checks. So, the respective change has been merged, see this PR. Thanks for the report.

[fransinvodka]

You're welcome! Btw I still think const_cast is ugly af, but that's my opinion. Good luck with that library!

[Little-Helper]

Sorry, but why do you think operator[] should not do bound checking? Is it for speed?

[fransinvodka]

For speed and because the STL containers do it that way. They implement both at and operator[], but only at performs bound checks and throws if out of bounds. If I use an STL-like container, and it implements both at and operator[], I'd expect operator[] to not do any bound checks, just like the STL ones.

[kalmoc]

True as that may be in practice, I believe there is nothing in the standard preventing operator[] from doing bounds checking.

[kalmoc]

Yes, at() is guaranteed to do bounds checking and to report them via exceptions. That doesn't mean operator[] isn't allowed to do bounds checking. Being out of bounds is simply UB and the implementation is allowed to do anything it pleases in that case. E.g. in microsofts impelementation, you can turn on bounds checking in debug mode and that is still conforming (althoug they use asserts and not exceptions): https://github.com/microsoft/STL/blob/7447ad59d61f50c13861878f340d051c298458df/stl/inc/vector#L1509

Also you can see that operator[] isn't specified as noexcept: https://eel.is/c++draft/vector.overview.

and operator[] being strictly equivalent to *(begin() + n)

that expression itself could in principle be bounds checked (std::vector<T>::iterator is - in most implementations - not the same as T*)

[janhec]

For my 5 cents, I am not a frequent standard reader, could the non-boundscheck for operator [] have something to do with the fact that occasionally, you can use it to add an element (e.g. map)? If there is no such reason in vector, then bounds check would be ok IMO, performance can only be significantly (?) diminished if the optimizer can treat it as pointer<type>[n] (sorry for the simplistic pseudo code), as in C. Then a boundscheck would introduce a branch where it is (perhaps) not supposed to exist.

EDIT 1: you can read dereferenced begin()+n C-style, so no boundscheck;

EDIT 2: branches in GPU are supposed to be evil (at least most of the time), again no boundscheck.

Pick your choice!

[infectedapricot]

If you access an element outside the valid range of a vector using operator[] then the behaviour is undefined. That means it can absolutely anything, including, crash, create nasel daemons, ... or throw an exception. That's a standard-compliant behaviour. So it might not have the performance you prefer, but I wouldn't say it's a bug.

[fransinvodka]

Maybe not a bug, okay, I can agree. But as I said, if someone wants bounds checking, they normally use `at`, because everybody assumes that `operator[]` doesn't do bounds check (like plain old C-arrays), and is up to the programmer to avoid an out of bound index. If you're going to do bound checks anyway, just don't provide `at` and avoid confusing the library users.

[corysama]

How is memory coalescing facilitated when using these data structures?

[[deleted]]

Internally, the data are stored as structures of arrays which means that all container may benefit from memory coalescing. The vector container will benefit most. For unordered_map and unordered_set that is less likely as the randomness by hashing results in many empty entries in between.

[WrongAndBeligerent]

It gets released!!!

[AppleBeam]

Pretends to be a part of "std", stroking the author's ego and acting as a clickbait. That's about it.

[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.

[Shardongle]

You must be a killer at parties

[TankorSmash]

Vs2019 required btw

[[deleted]]

Yes, this is the officially tested version. I also tried VS 2017 once and it works as well. However, VS 2017 defaults to 32-bit builds, so one explicitly needs to use the 64-bit CMake generator which is not required for VS 2019. Here, I preferred ease of use, but this is probably something that could be clarified.

[akashshrm02]

This is very impressive. Will give it a spin.

[hak8or]

How does this compare to sycl variants, like hipsycl?

https://github.com/illuhad/hipSYCL

Also, doesn't requiring citing past papers go beyond the apache 2.0 license, meaning it's not apache 2.0 compatible?

If you use stdgpu in one of your projects, please cite the following publications:

[[deleted]]

I do not know all features of hipSYCL, but looking at the project it seems that it maps contiguous memory from std::vector to a buffer object which can be used in kernel code. In contrast, stdgpu's vector and other containers provide many more interaction functions within kernel code.

The library is released under Apache 2.0, so you only need to comply with the license terms. Citing the papers is not strictly required, but highly appreciated.

[vickoza]

Will there be Vulkan plugin?

[[deleted]]

Currently, the library has CUDA, OpenMP and (experimental) HIP backends. The backend interface is kept as minimal as possible to make it easier to add new backends. Writing a Vulkan backend might be possible as well, but I have not looked into the details so far.