| Exemples | Documentation du doxygen (TODO) |
|---|
cuCollections ( cuco ) est une bibliothèque open source et en tête uniquement des structures de données simultanées accélérées par le GPU.
Semblable à la façon dont Thrust et Cub fournissent des algorithmes et primitives accélérés de type STL, cuCollections fournit des structures de données simultanées de type STL. cuCollections n'est pas un remplaçant en un à un pour les structures de données STL comme std::unordered_map . Au lieu de cela, il fournit des structures de données fonctionnellement similaires adaptées à une utilisation efficace avec les GPU.
cuCollections est toujours en cours de développement intense. Les utilisateurs doivent s'attendre à ce que les changements de rupture et le refactorisation soient courants.
11/01/2024 a affiné la window du terme comme bucket
01/08/2024 Déborder l'espace de noms experimental
01/02/2024 a déplacé le héritage static_map vers cuco::legacy Espace de noms
cuCollections est uniquement en tête et peut être incorporée manuellement dans votre projet en téléchargeant les en-têtes et en les plaçant dans votre arbre source.
cuCollections à un projet CMake cuCollections est conçue pour faciliter l'inclure dans un autre projet CMake. Le CMakeLists.txt exporte une cible cuco qui peut être liée 1 à une cible à configurer inclut les répertoires, les dépendances et les indicateurs de compilation nécessaires pour utiliser cuCollections dans votre projet.
Nous vous recommandons d'utiliser CMake Package Manager (CPM) pour récupérer cuCollections dans votre projet. Avec CPM, il est facile d'obtenir 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) Cela s'occupera de télécharger cuCollections à partir de GitHub et de rendre les en-têtes disponibles dans un endroit que l'on peut trouver par Cmake. Le lien avec la cible cuco fournira tout ce qui est nécessaire pour que cuco soit utilisé par la cible my_library .
1: cuCollections est uniquement en tête et il n'y a donc pas de composant binaire contre lequel "se lier". La terminologie de liaison provient de target_link_libraries de Cmake qui est toujours utilisée même pour les cibles de bibliothèque d'en-tête uniquement.
nvcc 11.5+ cuCollections dépend des bibliothèques suivantes:
Aucune action n'est requise de l'utilisateur pour satisfaire ces dépendances. Le script CMake de cuCollections est configuré pour rechercher d'abord ces bibliothèques du système, et s'ils ne sont pas trouvés, pour les récupérer automatiquement à partir de GitHub.
Étant donné que cuCollections est uniquement en tête, il n'y a rien à construire pour l'utiliser.
Pour construire les tests, les repères et les exemples:
cd $CUCO_ROOT
mkdir -p build
cd build
cmake .. # configure
make # build
ctest --test-dir tests # run testsLes binaires seront intégrés à:
build/tests/build/benchmarks/build/examples/ Alternativement, vous pouvez utiliser le script de construction situé sur ci/build.sh . L'appel de ce script sans arguments déclenchera une version complète qui sera située à build/local .
cd $CUCO_ROOT
ci/build.sh # configure and build
ctest --test-dir build/local/tests # run tests Pour une liste complète de toutes les options disponibles ainsi que des descriptions et des exemples, vous pouvez utiliser l'option ci/build.sh -h .
Par défaut, cuCollections utilise pre-commit.ci avec mirrors-clang-format pour formater automatiquement les fichiers C ++ / CUDA dans une demande de traction. Les utilisateurs doivent permettre l'option Allow edits by maintainers pour faire fonctionner le format automatique.
Facultativement, vous souhaiterez peut-être configurer un crochet pre-commit pour exécuter automatiquement clang-format lorsque vous vous engagez à git. Cela peut être fait en installant pre-commit via conda ou pip :
conda install -c conda-forge pre_commitpip install pre-commitpuis courir:
pre-commit install de la racine du référentiel cuCollections . Maintenant, le formatage de code sera exécuté chaque fois que vous commettez des modifications.
Vous pouvez également vouloir formater manuellement le code:
pre-commit run clang-format --all-files mirrors-clang-format garantit la version correcte de clang-format et évite les décalages de version. Les utilisateurs ne doivent pas utiliser clang-format directement sur la ligne de commande pour formater le code.
Doxygen est utilisé pour générer des pages HTML à partir des commentaires C ++ / CUDA dans le code source.
L'exemple suivant couvre la plupart des styles de commentaires et de balises de bloc Doxygen pour documenter le code C ++ / CUDA dans cuCollections .
/* *
* @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 utilise également le doxygène comme linter de documentation. Pour vérifier le style doxygen localement, courez
./ci/pre-commit/doxygen.sh Nous prévoyons d'ajouter de nombreuses structures de données simultanées accélérées par le GPU aux cuCollections . À l'heure actuelle, les deux produits phares sont des variantes de tables de hachage.
static_set cuco::static_set est un conteneur de taille fixe qui stocke des éléments uniques dans aucun ordre particulier. Voir la documentation Doxygen dans static_set.cuh pour des informations plus détaillées.
static_map cuco::static_map est une table de hachage de taille fixe utilisant l'adresse ouverte avec sondage linéaire. Voir la documentation Doxygen dans static_map.cuh pour des informations plus détaillées.
static_multimap cuco::static_multimap est une table de hachage de taille fixe qui prend en charge le stockage des clés équivalentes. Il utilise le double hachage par défaut et prend en charge le passage au sondage linéaire. Voir la documentation Doxygen dans static_multimap.cuh pour des informations plus détaillées.
static_multiset cuco::static_multiset est un conteneur de taille fixe qui prend en charge le stockage des clés équivalentes. Il utilise le double hachage par défaut et prend en charge le passage au sondage linéaire. Voir la documentation Doxygen dans static_multiset.cuh pour des informations plus détaillées.
dynamic_map cuco::dynamic_map relie plusieurs cuco::static_map s pour fournir une table de hachage qui peut se développer à mesure que les paires de valeurs clés sont insérées. Il fournit actuellement uniquement des API host-bulk. Voir la documentation DOXYGEN dans dynamic_map.cuh pour des informations plus détaillées.
hyperloglog cuco::hyperloglog implémente l'algorithme Hyperloglog ++ bien établi pour approximer le nombre d'éléments distincts dans un multiset / flux.
bloom_filter cuco::bloom_filter implémente un filtre de floraison bloqué pour les requêtes d'appartenance à ensemble approximatives.