cuCollections
1.0.0
| Beispiele | Doxygen -Dokumentation (Todo) |
|---|
cuCollections ( cuco ) ist eine Open-Source-Bibliothek mit nur einer Header mit GPU-beschleunigten, gleichzeitigen Datenstrukturen.
Ähnlich wie Thrust und CUM STL-ähnliche GPU-beschleunigte Algorithmen und Primitive liefern, liefert cuCollections STL-ähnliche gleichzeitige Datenstrukturen. cuCollections ist kein Eins-zu-Eins-Drop-In-Ersatz für STL-Datenstrukturen wie std::unordered_map . Stattdessen liefert es funktional ähnliche Datenstrukturen, die auf eine effiziente Verwendung mit GPUs zugeschnitten sind.
cuCollections steht noch unter starker Entwicklung. Benutzer sollten rechnen, dass sich Veränderungen und Refactoring häufig auswirken.
11/01/2024 verfeinert das window als bucket
01/08/2024 veraltete den experimental Namespace
01/02/2024 bewegte den Legacy static_map in cuco::legacy Namespace
cuCollections ist nur Header und kann manuell in Ihr Projekt aufgenommen werden, indem die Header heruntergeladen und in Ihren Quellbaum gelegt werden.
cuCollections zu einem CMAKE -Projekt cuCollections ist so konzipiert, dass es einfach ist, in ein anderes CMAKE -Projekt aufzunehmen. Die CMakeLists.txt exportiert ein cuco -Ziel, das 1 in ein Ziel zum Einrichten verknüpft werden kann, enthalten Verzeichnisse, Abhängigkeiten und kompilierte Flags, die erforderlich sind, um cuCollections in Ihrem Projekt zu verwenden.
Wir empfehlen, CMAKE Package Manager (CPM) zu verwenden, um cuCollections in Ihr Projekt zu holen. Bei CPM ist es cuCollections :
cmake_minimum_required ( VERSION 3.23.1 FATAL_ERROR)
include ( path /to/CPM.cmake)
CPMAddPackage(
NAME cuco
GITHUB_REPOSITORY NVIDIA/cuCollections
GIT_TAG dev
OPTIONS
"BUILD_TESTS OFF"
"BUILD_BENCHMARKS OFF"
"BUILD_EXAMPLES OFF"
)
target_link_libraries (my_library cuco) Dadurch wird sich das Herunterladen von cuCollections von Github und die verfügbaren Header an einem Ort zur Verfügung stellen, der von CMAKE zu finden ist. Durch die Verknüpfung mit dem cuco -Ziel wird alles bereitgestellt, der für cuco vom my_library -Ziel verwendet wird.
1: cuCollections ist nur Header, und daher gibt es keine binäre Komponente, gegen die man "verknüpfen" kann. Die Verknüpfungsterminologie stammt aus CMAKEs target_link_libraries , die auch für Bibliotheksziele nur für Header nur verwendet wird.
nvcc 11.5+ cuCollections hängt von den folgenden Bibliotheken ab:
Der Benutzer ist keine Aktion erforderlich, um diese Abhängigkeiten zu erfüllen. Das CMake -Skript von cuCollections ist so konfiguriert, dass das System zuerst das System nach diesen Bibliotheken durchsucht und wenn sie nicht gefunden werden, um sie automatisch von GitHub abzurufen.
Da cuCollections nur Header ist, gibt es nichts zu erstellen, um es zu verwenden.
Um die Tests, Benchmarks und Beispiele zu erstellen: Beispiele:
cd $CUCO_ROOT
mkdir -p build
cd build
cmake .. # configure
make # build
ctest --test-dir tests # run testsBinärdateien werden eingebaut in:
build/tests/build/benchmarks/build/examples/ Alternativ können Sie das Build -Skript unter ci/build.sh verwenden. Wenn Sie dieses Skript ohne Argumente aufrufen, wird ein vollständiger Build ausgelöst, der sich in build/local befindet.
cd $CUCO_ROOT
ci/build.sh # configure and build
ctest --test-dir build/local/tests # run tests Für eine umfassende Liste aller verfügbaren Optionen sowie Beschreibungen und Beispiele können Sie die Option ci/build.sh -h verwenden.
Standardmäßig verwendet cuCollections pre-commit.ci zusammen mit mirrors-clang-format , um die C ++/CUDA-Dateien automatisch in einer Pull-Anforderung zu formatieren. Benutzer sollten die Option Allow edits by maintainers ermöglichen, um automatisch formatiert zu werden.
Optional möchten Sie möglicherweise einen pre-commit Haken einrichten, um clang-format automatisch auszuführen, wenn Sie ein Git-Commit einstellen. Dies kann durch die Installation von pre-commit über conda oder pip erfolgen:
conda install -c conda-forge pre_commitpip install pre-commitund dann rennen:
pre-commit install Aus der Wurzel des cuCollections -Repositorys. Jetzt wird die Code -Formatierung jedes Mal ausgeführt, wenn Sie Änderungen begehen.
Möglicherweise möchten Sie den Code auch manuell formatieren:
pre-commit run clang-format --all-files mirrors-clang-format garantiert die richtige Version von clang-format und vermeidet Versionsfehlanpassungen. Benutzer sollten clang-format nicht direkt in der Befehlszeile verwenden, um den Code zu formatieren.
Doxygen wird verwendet, um HTML -Seiten aus den C ++/CUDA -Kommentaren im Quellcode zu generieren.
Das folgende Beispiel deckt die meisten Doxygen -Block -Kommentare und Tag -Stile für die Dokumentation von C ++/CUDA -Code in cuCollections ab.
/* *
* @file source_file.cpp
* @brief Description of source file contents
*
* Longer description of the source file contents.
*/
/* *
* @brief Short, one sentence description of the class.
*
* Longer, more detailed description of the class.
*
* A detailed description must start after a blank line.
*
* @tparam T Short description of each template parameter
* @tparam U Short description of each template parameter
*/
template < typename T, typename U>
class example_class {
void get_my_int (); // /< Simple members can be documented like this
void set_my_int ( int value ); // /< Try to use descriptive member names
/* *
* @brief Short, one sentence description of the member function.
*
* A more detailed description of what this function does and what
* its logic does.
*
* @param[in] first This parameter is an input parameter to the function
* @param[in,out] second This parameter is used both as an input and output
* @param[out] third This parameter is an output of the function
*
* @return The result of the complex function
*/
T complicated_function ( int first, double * second, float * third)
{
// Do not use doxygen-style block comments
// for code logic documentation.
}
private:
int my_int; // /< An example private member variable
}; cuCollections verwendet Doxygen auch eine Dokumentationslinter. Um den Doxygen -Stil lokal zu überprüfen, laufen Sie
./ci/pre-commit/doxygen.sh Wir planen, viele GPU-beschleunigte, gleichzeitige Datenstrukturen zu cuCollections hinzuzufügen. Ab sofort sind die beiden Flaggschiffe Varianten von Hash -Tabellen.
static_set cuco::static_set ist ein Container mit fester Größe, der einzigartige Elemente in keiner bestimmten Reihenfolge speichert. Weitere Informationen finden Sie in der Doxygen -Dokumentation in static_set.cuh .
static_map cuco::static_map ist eine Hash-Tabelle mit fester Größe, die eine offene Adressierung mit linearer Prüfung verwendet. Weitere Informationen finden Sie in der Doxygen -Dokumentation in static_map.cuh .
static_multimap cuco::static_multimap ist eine Hash-Tabelle mit fester Größe, die das Speichern von äquivalenten Schlüssel unterstützt. Es verwendet standardmäßig doppelte Hashing und unterstützt das Umschalten auf lineare Prüfung. Weitere Informationen finden Sie in der Doxygen -Dokumentation in static_multimap.cuh .
static_multiset cuco::static_multiset ist ein Behälter mit fester Größe, der das Speichern von äquivalenten Schlüssel unterstützt. Es verwendet standardmäßig doppelte Hashing und unterstützt das Umschalten auf lineare Prüfung. Weitere Informationen finden Sie in der Doxygen -Dokumentation in static_multiset.cuh .
dynamic_map cuco::dynamic_map verlinkt mehrere cuco::static_map S, um eine Hash-Tabelle bereitzustellen, die wachsen kann, wenn Schlüsselwertpaare eingefügt werden. Derzeit liefert es nur Host-Bulk-APIs. Weitere Informationen finden Sie in der Doxygen -Dokumentation in dynamic_map.cuh .
hyperloglog cuco::hyperloglog implementiert den etablierten Hyperloglog ++ -Angorithmus zur Annäherung der Anzahl verschiedener Elemente in einem Multiset/Stream.
bloom_filter cuco::bloom_filter implementiert einen blockierten Bloom -Filter für ungefähre Abfragen der Mitgliedschaftsmitgliedschaft.
