Boost.Compute
Bolt
| Boost.Compute | Bolt | |
|---|---|---|
| - | 3 | |
| 1,547 | 373 | |
| 0.7% | - | |
| 0.0 | 0.0 | |
| about 2 months ago | over 8 years ago | |
| C++ | C++ | |
| gtkbook License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Boost.Compute
We haven't tracked posts mentioning Boost.Compute yet.
Tracking mentions began in Dec 2020.
Bolt
- AMD's CDNA 3 Compute Architecture
-
High quality OpenCL compute libraries
what I'm saying is there are options on that that make it more likely for what you're looking to exist; I haven't surveyed the existing libs as much but without templates and the integration of single source you're not bound to find libraries to exist; it's why opencl doesn't have those things really; however I name droped the amd targetted OpenCL thrust equivalent - https://github.com/HSA-Libraries/Bolt - I don't know if you can really achieve opencl multi-accelerator compatibility with it though.
-
Nvidia in the Valley
OpenCL had a bit of a "second-mover curse" where instead of trying to solve one problem (GPGPU acceleration) it tried to solve everything (a generalized framework for heterogeneous dispatch) and it just kinda sucks to actually use. It's not that it's slower or faster, in principle it should be the same speed when dispatched to the hardware (+/- any C/C++ optimization gotchas of course), but it just requires an obscene amount of boilerplate to "draw the first triangle" (or, launch the first kernel), much like Vulkan.
HIP was supposed to rectify this, but now you're buying into AMD's custom language and its limitations... and there are limitations, things that CUDA can do that HIP can't (texture unit access was an early one - and texture units aren't just for texturing, they're for coalescing all kinds of 2d/3d/higher-dimensional memory access). And AMD has a history of abandoning these projects after a couple years and leaving them behind and unsupported... like their Thrust framework counterpart, Bolt, which hasn't been updated in 8 years now.
https://github.com/HSA-Libraries/Bolt
The old bit about "Vendor B" leaving behind a "trail of projects designed to pad resumes and show progress to middle managers" still reigns absolutely true with AMD. AMD has a big uphill climb in general to shake this reputation about being completely unserious with their software... and I'm not even talking about drivers here.
http://richg42.blogspot.com/2014/05/the-truth-on-opengl-driv...
What are some alternatives?
moodycamel - A fast multi-producer, multi-consumer lock-free concurrent queue for C++11
Thrust - [ARCHIVED] The C++ parallel algorithms library. See https://github.com/NVIDIA/cccl
junction - Concurrent data structures in C++
ArrayFire - ArrayFire: a general purpose GPU library.
HPX - The C++ Standard Library for Parallelism and Concurrency
Taskflow - A General-purpose Task-parallel Programming System using Modern C++
C++React - C++React: A reactive programming library for C++11.
VexCL - VexCL is a C++ vector expression template library for OpenCL/CUDA/OpenMP