From 2c8747612f0652827dc11aaa8ce72fd042623459 Mon Sep 17 00:00:00 2001 From: Daniel Arndt Date: Tue, 13 Aug 2024 09:37:17 -0600 Subject: [PATCH] Fix some typos and check via GitHub actions (#564) * Fix typos * Add GitHub Action * Pin crate-ci/typos version. --- .github/workflows/typos.yml | 17 +++++++++++++++++ .typos.toml | 15 +++++++++++++++ docs/source/API/algorithms/Random-Number.rst | 4 ++-- .../API/algorithms/std-algorithms-index.rst | 2 +- ...PartioningOps.rst => StdPartitioningOps.rst} | 0 .../algorithms/std-algorithms/all/StdEqual.rst | 2 +- .../algorithms/std-algorithms/all/StdFind.rst | 2 +- .../std-algorithms/all/StdFindEnd.rst | 2 +- .../std-algorithms/all/StdIsSortedUntil.rst | 2 +- .../all/StdLexicographicalCompare.md | 2 +- .../std-algorithms/all/StdMismatch.md | 2 +- .../std-algorithms/all/StdPartitionPoint.md | 4 ++-- .../std-algorithms/all/StdRemoveCopyIf.rst | 2 +- .../std-algorithms/all/StdReverse.rst | 2 +- docs/source/API/alphabetical.rst | 4 ++-- docs/source/API/containers/Unordered-Map.rst | 2 +- docs/source/API/core/Detection-Idiom.rst | 2 +- docs/source/API/core/Macros.rst | 2 +- docs/source/API/core/Task-Parallelism.rst | 2 +- .../source/API/core/atomics/atomic_fetch_op.rst | 2 +- .../source/API/core/atomics/atomic_op_fetch.rst | 2 +- .../API/core/builtinreducers/MinMaxLoc.rst | 2 +- docs/source/API/core/execution_spaces.rst | 4 ++-- .../InitializationSettings.rst | 2 +- .../API/core/initialize_finalize/finalize.rst | 2 +- docs/source/API/core/memory_spaces.rst | 6 +++--- .../API/core/numerics/bit-manipulation.rst | 6 +++--- .../API/core/policies/TeamHandleConcept.rst | 4 ++-- docs/source/API/core/spaces/partition_space.rst | 2 +- docs/source/API/core/utilities/experimental.md | 2 +- .../source/API/core/utilities/min_max_clamp.rst | 6 +++--- .../ProgrammingGuide/Atomic-Operations.md | 6 +++--- docs/source/ProgrammingGuide/Compatibility.md | 2 +- .../Kokkos-and-Virtual-Functions.md | 6 +++--- .../source/ProgrammingGuide/ProgrammingModel.md | 2 +- docs/source/ProgrammingGuide/SIMD.md | 2 +- docs/source/known-issues.rst | 2 +- docs/source/quick_start.rst | 2 +- 38 files changed, 82 insertions(+), 50 deletions(-) create mode 100644 .github/workflows/typos.yml create mode 100644 .typos.toml rename docs/source/API/algorithms/std-algorithms/{StdPartioningOps.rst => StdPartitioningOps.rst} (100%) diff --git a/.github/workflows/typos.yml b/.github/workflows/typos.yml new file mode 100644 index 000000000..e7ddbbc27 --- /dev/null +++ b/.github/workflows/typos.yml @@ -0,0 +1,17 @@ +name: Test GitHub Action +on: [push, pull_request] + +jobs: + run: + name: Spell Check with Typos + runs-on: ubuntu-latest + steps: + - name: Checkout Actions Repository + uses: actions/checkout@v4 + + - name: Writes changes in the local checkout + uses: crate-ci/typos@v1.23.6 + with: + write_changes: true + files: ./docs/source/ProgrammingGuide/ ./docs/source/API/ ./docs/source/*.rst ./docs/source/*.md + config: ./.typos.toml diff --git a/.typos.toml b/.typos.toml new file mode 100644 index 000000000..ca35b9763 --- /dev/null +++ b/.typos.toml @@ -0,0 +1,15 @@ +[default] +# Don't check text that matches the following regexes' +extend-ignore-re = [] + +[default.extend-identifiers] +# Don't correct these whole identifiers (word-groups) + +[default.extend-words] +# Don't correct these word (parts) +countr = "countr" +OT = "OT" + +# Don't check the following files +[files] +extend-exclude = [] diff --git a/docs/source/API/algorithms/Random-Number.rst b/docs/source/API/algorithms/Random-Number.rst index cc1184d73..f8fa740d8 100644 --- a/docs/source/API/algorithms/Random-Number.rst +++ b/docs/source/API/algorithms/Random-Number.rst @@ -110,9 +110,9 @@ are collectives, i.e. all functions can be called inside conditionals. void free_state(Generator_Type Gen); } -A Pool of Generators are intialized using a starting seed and establishing +A Pool of Generators are initialized using a starting seed and establishing a pool_size of num_states. The Random_XorShift64 generator is used in serial -to initialize all states making the intialization process platform independent +to initialize all states making the initialization process platform independent and deterministic. Requesting a generator locks it's state guaranteeing that each thread has a private (independent) generator. (Note, getting a state on a Cuda device involves atomics, making it non-deterministic!) diff --git a/docs/source/API/algorithms/std-algorithms-index.rst b/docs/source/API/algorithms/std-algorithms-index.rst index dea000f46..87a282471 100644 --- a/docs/source/API/algorithms/std-algorithms-index.rst +++ b/docs/source/API/algorithms/std-algorithms-index.rst @@ -9,5 +9,5 @@ Std Algorithms ./std-algorithms/StdModSeq ./std-algorithms/StdNonModSeq ./std-algorithms/StdNumeric - ./std-algorithms/StdPartioningOps + ./std-algorithms/StdPartitioningOps ./std-algorithms/StdSorting diff --git a/docs/source/API/algorithms/std-algorithms/StdPartioningOps.rst b/docs/source/API/algorithms/std-algorithms/StdPartitioningOps.rst similarity index 100% rename from docs/source/API/algorithms/std-algorithms/StdPartioningOps.rst rename to docs/source/API/algorithms/std-algorithms/StdPartitioningOps.rst diff --git a/docs/source/API/algorithms/std-algorithms/all/StdEqual.rst b/docs/source/API/algorithms/std-algorithms/all/StdEqual.rst index a220256c8..ab814d77d 100644 --- a/docs/source/API/algorithms/std-algorithms/all/StdEqual.rst +++ b/docs/source/API/algorithms/std-algorithms/all/StdEqual.rst @@ -217,7 +217,7 @@ Corner cases when ``false`` is returned: - if ``view1.extent(0) != view2.extent(1)`` for all overloads accepting Views -- if the lenght of the range ``[first1, last)`` is not equal to lenght of ``[first2,last2)`` +- if the length of the range ``[first1, last)`` is not equal to length of ``[first2,last2)`` Example diff --git a/docs/source/API/algorithms/std-algorithms/all/StdFind.rst b/docs/source/API/algorithms/std-algorithms/all/StdFind.rst index ced0071e1..661dbcc6c 100644 --- a/docs/source/API/algorithms/std-algorithms/all/StdFind.rst +++ b/docs/source/API/algorithms/std-algorithms/all/StdFind.rst @@ -96,7 +96,7 @@ Return Value or ``last`` if no element is found - (3,4,6): iterator to the first element that equals ``value``, - or ``Kokkos::Experimental::end(view)`` if no elememt is found + or ``Kokkos::Experimental::end(view)`` if no element is found Example diff --git a/docs/source/API/algorithms/std-algorithms/all/StdFindEnd.rst b/docs/source/API/algorithms/std-algorithms/all/StdFindEnd.rst index 600bfc2da..425c27575 100644 --- a/docs/source/API/algorithms/std-algorithms/all/StdFindEnd.rst +++ b/docs/source/API/algorithms/std-algorithms/all/StdFindEnd.rst @@ -173,7 +173,7 @@ Return Value ~~~~~~~~~~~~ Iterator to the beginning of the last occurrence of the sequence ``[s_first, s_last)`` -in range ``[first, last)``, or the last occurence of ``s_view`` in ``view``. +in range ``[first, last)``, or the last occurrence of ``s_view`` in ``view``. If ``[s_first, s_last)`` or ``[first, last)`` is empty, ``last`` is returned. diff --git a/docs/source/API/algorithms/std-algorithms/all/StdIsSortedUntil.rst b/docs/source/API/algorithms/std-algorithms/all/StdIsSortedUntil.rst index 07a1ac473..1c54a13e4 100644 --- a/docs/source/API/algorithms/std-algorithms/all/StdIsSortedUntil.rst +++ b/docs/source/API/algorithms/std-algorithms/all/StdIsSortedUntil.rst @@ -115,4 +115,4 @@ Parameters and Requirements Return Value ~~~~~~~~~~~~ -- The last iterator ``it`` for which range ``[first, it)`` is sorted and where the following is true: ``std::is_same_v``, or for which range ``[Kokkos::Experimental::begin(view), it)`` is sorted. For this second case, note that ``it`` is computed as: ``Kokkos::Experimental::begin(view) + increment`` where ``increment`` is found in the algoritm. +- The last iterator ``it`` for which range ``[first, it)`` is sorted and where the following is true: ``std::is_same_v``, or for which range ``[Kokkos::Experimental::begin(view), it)`` is sorted. For this second case, note that ``it`` is computed as: ``Kokkos::Experimental::begin(view) + increment`` where ``increment`` is found in the algorithm. diff --git a/docs/source/API/algorithms/std-algorithms/all/StdLexicographicalCompare.md b/docs/source/API/algorithms/std-algorithms/all/StdLexicographicalCompare.md index 11aad795a..c985d4576 100644 --- a/docs/source/API/algorithms/std-algorithms/all/StdLexicographicalCompare.md +++ b/docs/source/API/algorithms/std-algorithms/all/StdLexicographicalCompare.md @@ -76,7 +76,7 @@ Elements (5,6,7,8) are compared using `comp`. - execution space instance - `label`: - - 1,5: The default string is "Kokkos::lexicographical_compare_iterator_api_defaul". + - 1,5: The default string is "Kokkos::lexicographical_compare_iterator_api_default". - 3,7: The default string is "Kokkos::lexicographical_compare_view_api_default". - `first1`, `last1`, `first2`, `last2`: diff --git a/docs/source/API/algorithms/std-algorithms/all/StdMismatch.md b/docs/source/API/algorithms/std-algorithms/all/StdMismatch.md index 4f2eea86c..6f55b77fa 100644 --- a/docs/source/API/algorithms/std-algorithms/all/StdMismatch.md +++ b/docs/source/API/algorithms/std-algorithms/all/StdMismatch.md @@ -134,7 +134,7 @@ view_type b("b", 15); // fill a,b somehow // create functor -MisMatchFunctor p(); +MismatchFunctor p(); Kokkos::pair mismatch_index = KE::mismatch(exespace, KE::begin(a), KE::end(a), KE::begin(b), KE::end(b) p); diff --git a/docs/source/API/algorithms/std-algorithms/all/StdPartitionPoint.md b/docs/source/API/algorithms/std-algorithms/all/StdPartitionPoint.md index f0705c9cc..baf47cf58 100644 --- a/docs/source/API/algorithms/std-algorithms/all/StdPartitionPoint.md +++ b/docs/source/API/algorithms/std-algorithms/all/StdPartitionPoint.md @@ -43,7 +43,7 @@ Assumes the range (or the view) already to be partitioned. ## Parameters and Requirements -- `exespace`, `first`, `last`, `view`, `pred`: same as in [`is_partioned`](./StdIsPartitioned) +- `exespace`, `first`, `last`, `view`, `pred`: same as in [`is_partitioned`](./StdIsPartitioned) - execution space instance - `label`: - used to name the implementation kernels for debugging purposes @@ -52,5 +52,5 @@ Assumes the range (or the view) already to be partitioned. ## Return -Iterator to the elment *after* the last element in the first partition, +Iterator to the element *after* the last element in the first partition, or `last` if all elements satisfy `pred`. \ No newline at end of file diff --git a/docs/source/API/algorithms/std-algorithms/all/StdRemoveCopyIf.rst b/docs/source/API/algorithms/std-algorithms/all/StdRemoveCopyIf.rst index 136849738..32dd0efa8 100644 --- a/docs/source/API/algorithms/std-algorithms/all/StdRemoveCopyIf.rst +++ b/docs/source/API/algorithms/std-algorithms/all/StdRemoveCopyIf.rst @@ -7,7 +7,7 @@ Description ----------- Copies the elements from a range to a new range starting at ``first_to`` or from ``view_from`` -to ``view_dest`` omitting thos for which ``pred`` returns ``true``. +to ``view_dest`` omitting those for which ``pred`` returns ``true``. Interface --------- diff --git a/docs/source/API/algorithms/std-algorithms/all/StdReverse.rst b/docs/source/API/algorithms/std-algorithms/all/StdReverse.rst index ddc571a56..8334f6b48 100644 --- a/docs/source/API/algorithms/std-algorithms/all/StdReverse.rst +++ b/docs/source/API/algorithms/std-algorithms/all/StdReverse.rst @@ -7,7 +7,7 @@ Header: ```` Description ----------- -Reverses ther order of the elements in a range or in rank-1 ``View``. +Reverses the order of the elements in a range or in rank-1 ``View``. Interface --------- diff --git a/docs/source/API/alphabetical.rst b/docs/source/API/alphabetical.rst index a45e0becd..adf87b068 100644 --- a/docs/source/API/alphabetical.rst +++ b/docs/source/API/alphabetical.rst @@ -40,7 +40,7 @@ Containers +----------------------------------------------------+---------------------------------------+----------+----------------------------------------------------------------------------------------------------------------+ | ErrorReporter | `Containers `_ | View | A class supporting error recording in parallel code. | +----------------------------------------------------+---------------------------------------+----------+----------------------------------------------------------------------------------------------------------------+ -| `OffsetView `_ | `Containers `_ | View | View structure supporting non-zero start indicies. | +| `OffsetView `_ | `Containers `_ | View | View structure supporting non-zero start indices. | +----------------------------------------------------+---------------------------------------+----------+----------------------------------------------------------------------------------------------------------------+ | `ScatterView `_ | `Containers `_ | View | View structure to transpartently support atomic and data replication strategies for scatter-reduce algorithms. | +----------------------------------------------------+---------------------------------------+----------+----------------------------------------------------------------------------------------------------------------+ @@ -162,7 +162,7 @@ Core +--------------------------------------------------------------------------------------+---------------------------+------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ | `MinMax `_ | `Core `_ | `Built-in Reducers `_ | Reducer for Reduction providing both minimum and maximum | +--------------------------------------------------------------------------------------+---------------------------+------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ -| `MinMaxLoc `_ | `Core `_ | `Built-in Reducers `_ | Reducer for Reduction providing both minimum and maximum and associated indicies | +| `MinMaxLoc `_ | `Core `_ | `Built-in Reducers `_ | Reducer for Reduction providing both minimum and maximum and associated indices | +--------------------------------------------------------------------------------------+---------------------------+------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ | `OpenMP `_ | `Core `_ | `Spaces `_ | Execution space using non-target OpenMP parallel execution mechanisms. | +--------------------------------------------------------------------------------------+---------------------------+------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ diff --git a/docs/source/API/containers/Unordered-Map.rst b/docs/source/API/containers/Unordered-Map.rst index 0e05d883e..fa4807297 100644 --- a/docs/source/API/containers/Unordered-Map.rst +++ b/docs/source/API/containers/Unordered-Map.rst @@ -147,7 +147,7 @@ There are 3 potential states for every insertion which are reported by the ``Uno - ``failed`` means that either the capacity of the map was exhausted or that a free index was not found with a bounded search of the internal atomic bitset. A ``failed`` insertion requires the user to increase - the capacity (``rehash``) and restart the algoritm. + the capacity (``rehash``) and restart the algorithm. .. code-block:: cpp diff --git a/docs/source/API/core/Detection-Idiom.rst b/docs/source/API/core/Detection-Idiom.rst index 4f3a910ea..cbb1fb3b9 100644 --- a/docs/source/API/core/Detection-Idiom.rst +++ b/docs/source/API/core/Detection-Idiom.rst @@ -20,7 +20,7 @@ API // VOID_T and DETECTOR are exposition-only and not intended to be used directly. - // Convienent metafunction to leverage SFINAE + // Convenient metafunction to leverage SFINAE template using VOID_T = void; diff --git a/docs/source/API/core/Macros.rst b/docs/source/API/core/Macros.rst index f30c98b8a..b8fb3abd9 100644 --- a/docs/source/API/core/Macros.rst +++ b/docs/source/API/core/Macros.rst @@ -121,7 +121,7 @@ Kokkos was compiled with. Third-Party Library Settings ---------------------------- -These defines give information about what third-party libaries Kokkos was compiled with. +These defines give information about what third-party libraries Kokkos was compiled with. +-------------------------------+-----------------------------------------------------------------------------------------------------------------------+ | Macro | Description | diff --git a/docs/source/API/core/Task-Parallelism.rst b/docs/source/API/core/Task-Parallelism.rst index b317bc2ad..f1653f879 100644 --- a/docs/source/API/core/Task-Parallelism.rst +++ b/docs/source/API/core/Task-Parallelism.rst @@ -9,7 +9,7 @@ Kokkos has support for lightweight task-based programming, which is currently pr Will Kokkos Tasking work for my problem? ---------------------------------------- -Not all task-based problems are a good fit for the current Kokkos approach to tasking. Currently, the tasking interface in Kokkos is targetted at problems with kernels far too small to overcome the inherent overhead of top-level Kokkos data parallel launches—that is, small but plentiful data parallel tasks with a non-trivial dependency structure. For tasks that fit this general scale model but have (very) trivial dependency structures, it may be easier to use `hierarchical parallelism <../../ProgrammingGuide/HierarchicalParallelism.html>`_, potentially with a ``Kokkos::Schedule`` scheduling policy (see, for instance, `this page `_) for load balancing if necessary. +Not all task-based problems are a good fit for the current Kokkos approach to tasking. Currently, the tasking interface in Kokkos is targeted at problems with kernels far too small to overcome the inherent overhead of top-level Kokkos data parallel launches—that is, small but plentiful data parallel tasks with a non-trivial dependency structure. For tasks that fit this general scale model but have (very) trivial dependency structures, it may be easier to use `hierarchical parallelism <../../ProgrammingGuide/HierarchicalParallelism.html>`_, potentially with a ``Kokkos::Schedule`` scheduling policy (see, for instance, `this page `_) for load balancing if necessary. Basic Usage ----------- diff --git a/docs/source/API/core/atomics/atomic_fetch_op.rst b/docs/source/API/core/atomics/atomic_fetch_op.rst index 3078d0f84..678793c6a 100644 --- a/docs/source/API/core/atomics/atomic_fetch_op.rst +++ b/docs/source/API/core/atomics/atomic_fetch_op.rst @@ -94,7 +94,7 @@ Description Atomically executes ``*ptr_to_value -= value``. :param ptr_to_value: address of the value to be updated - :param value: value to be substracted.. + :param value: value to be subtracted.. .. cppkokkos:function:: template T atomic_fetch_xor(T* const ptr_to_value, const T value); diff --git a/docs/source/API/core/atomics/atomic_op_fetch.rst b/docs/source/API/core/atomics/atomic_op_fetch.rst index 9df9f436c..17c191940 100644 --- a/docs/source/API/core/atomics/atomic_op_fetch.rst +++ b/docs/source/API/core/atomics/atomic_op_fetch.rst @@ -104,7 +104,7 @@ Description * ``ptr_to_value``: address of the to be updated value. - * ``value``: value to be substracted. + * ``value``: value to be subtracted. .. cppkokkos:function:: template T atomic_xor_fetch(T* const ptr_to_value, const T value); diff --git a/docs/source/API/core/builtinreducers/MinMaxLoc.rst b/docs/source/API/core/builtinreducers/MinMaxLoc.rst index b543db94c..5777a47e2 100644 --- a/docs/source/API/core/builtinreducers/MinMaxLoc.rst +++ b/docs/source/API/core/builtinreducers/MinMaxLoc.rst @@ -4,7 +4,7 @@ .. role:: cppkokkos(code) :language: cppkokkos -Specific implementation of `ReducerConcept `_ storing both the minimum and maximum values with corresponding indicies +Specific implementation of `ReducerConcept `_ storing both the minimum and maximum values with corresponding indices Header File: ```` diff --git a/docs/source/API/core/execution_spaces.rst b/docs/source/API/core/execution_spaces.rst index 6bcc4b294..ef0d1fac9 100644 --- a/docs/source/API/core/execution_spaces.rst +++ b/docs/source/API/core/execution_spaces.rst @@ -115,7 +115,7 @@ Aliases based on configuration ``Kokkos::DefaultExecutionSpace`` is an alias of |ExecutionSpaceConceptType|_ pointing to an ``ExecutionSpace`` based on the current configuration of Kokkos. It is set to the highest available in the hierarchy ``device,host-parallel,host-serial``. -It also serves as default for optionally specified template prameters of |ExecutionSpaceConceptType|_. +It also serves as default for optionally specified template parameters of |ExecutionSpaceConceptType|_. ``Kokkos::DefaultHostExecutionSpace`` ------------------------------------- @@ -338,6 +338,6 @@ Non Member Facilities * ``template struct is_execution_space;``: typetrait to check whether a class is a execution space. -* ``template struct SpaceAccessibility;``: typetraits to check whether two spaces are compatible (assignable, deep_copy-able, accessable). (see |KokkosSpaceAccessibility|_) +* ``template struct SpaceAccessibility;``: typetraits to check whether two spaces are compatible (assignable, deep_copy-able, accessible). (see |KokkosSpaceAccessibility|_) * ``bool operator==(const execution_space& lhs, const execution_space& rhs)``: tests whether the two space instances (of the same type) are identical. diff --git a/docs/source/API/core/initialize_finalize/InitializationSettings.rst b/docs/source/API/core/initialize_finalize/InitializationSettings.rst index 214f0bcb8..3d9fee852 100644 --- a/docs/source/API/core/initialize_finalize/InitializationSettings.rst +++ b/docs/source/API/core/initialize_finalize/InitializationSettings.rst @@ -17,7 +17,7 @@ Usage: .. versionadded:: 3.7 ``InitializationSettings`` is a class that can be used to define the settings for - initializating Kokkos programmatically without having to call the two parameter + initializing Kokkos programmatically without having to call the two parameter form (``argc`` and ``argv``) of `Kokkos::initialize() `_. It was introduced as a replacement for the `Kokkos::InitArguments `_ structure. diff --git a/docs/source/API/core/initialize_finalize/finalize.rst b/docs/source/API/core/initialize_finalize/finalize.rst index cc1263132..8f5fb8f08 100644 --- a/docs/source/API/core/initialize_finalize/finalize.rst +++ b/docs/source/API/core/initialize_finalize/finalize.rst @@ -18,7 +18,7 @@ resources. Once this function is called, no Kokkos API functions (not even `Kokkos::initialize `_) may be called, except for ``Kokkos::is_initialized`` or ``Kokkos::is_finalized``. -The user must ensure that all Kokkos objects (e.g. ``Kokkos::View``) are detroyed +The user must ensure that all Kokkos objects (e.g. ``Kokkos::View``) are destroyed before ``Kokkos::finalize`` gets called. Programs are ill-formed if they do not call this function after calling `Kokkos::initialize `_. diff --git a/docs/source/API/core/memory_spaces.rst b/docs/source/API/core/memory_spaces.rst index 5ddf12e7e..22488da0f 100644 --- a/docs/source/API/core/memory_spaces.rst +++ b/docs/source/API/core/memory_spaces.rst @@ -79,7 +79,7 @@ Memory Spaces ``Kokkos::SharedSpace`` :sup:`since 4.0` is a |MemorySpaceType|_ alias representing memory that can be accessed by any enabled |ExecutionSpaceType|_. To achieve this, the memory can be moved to and from the local memory of the processing units represented by the ``ExecutionSpaces``. The movement is done automatically by the OS and driver at the moment of access. If not currently located in the local memory of the accessing processing unit, the memory is moved in chunks (size is backend dependent). These chunks can be moved independently (e.g. only the part that is accessed on the GPU is moved to the GPU) and are treated like local memory while residing on the processing unit. For details, see |TheDocumentationOnTheMemorySpaceConcept|_. Availability can be checked with the preprocessor define ``KOKKOS_HAS_SHARED_SPACE`` or the ``constexpr bool Kokkos::has_shared_space``. -For the following backends ``Kokkos::SharedSpace`` is pointing to the correspoinding |MemorySpaceType|_: +For the following backends ``Kokkos::SharedSpace`` is pointing to the corresponding |MemorySpaceType|_: * Cuda -> ``CudaUVMSpace`` * HIP -> ``HIPManagedSpace`` @@ -89,9 +89,9 @@ For the following backends ``Kokkos::SharedSpace`` is pointing to the correspoin ``Kokkos::SharedHostPinnedSpace`` --------------------------------- -``Kokkos::SharedHostPinnedSpace`` :sup:`since 4.0` is a |MemorySpaceType|_ alias which is accessible by all enabled |ExecutionSpaceTypes|_. The memory stays pinned on the host and is availabe on the device via zero copy access in small chunks (cache lines, memory pages, etc. depending on the backend). Writes to the memory in one ``ExecutionSpace`` become visible in other ``ExecutionSpaces`` at synchronization events. Which events trigger a synchronization depend on the backend specifics. Nevertheless, fences are synchronization events on all backends. +``Kokkos::SharedHostPinnedSpace`` :sup:`since 4.0` is a |MemorySpaceType|_ alias which is accessible by all enabled |ExecutionSpaceTypes|_. The memory stays pinned on the host and is available on the device via zero copy access in small chunks (cache lines, memory pages, etc. depending on the backend). Writes to the memory in one ``ExecutionSpace`` become visible in other ``ExecutionSpaces`` at synchronization events. Which events trigger a synchronization depend on the backend specifics. Nevertheless, fences are synchronization events on all backends. Availability can be checked with the preprocessor define ``KOKKOS_HAS_SHARED_HOST_PINNED_SPACE`` or the ``constexpr bool Kokkos::has_shared_host_pinned_space``. -For the following backends ``Kokkos::SharedHostPinnedSpace`` is pointing to the correspoinding |MemorySpaceType|_: +For the following backends ``Kokkos::SharedHostPinnedSpace`` is pointing to the corresponding |MemorySpaceType|_: * Cuda -> ``CudaHostPinnedSpace`` * HIP -> ``HipHostPinnedSpace`` diff --git a/docs/source/API/core/numerics/bit-manipulation.rst b/docs/source/API/core/numerics/bit-manipulation.rst index 6c58918f5..6c72bb2a7 100644 --- a/docs/source/API/core/numerics/bit-manipulation.rst +++ b/docs/source/API/core/numerics/bit-manipulation.rst @@ -11,13 +11,13 @@ Bit manipulation .. |KokkosBitManipulation| replace:: ```` -.. _StandarLibraryHeaderBit: https://en.cppreference.com/w/cpp/header/bit +.. _StandardLibraryHeaderBit: https://en.cppreference.com/w/cpp/header/bit -.. |StandarLibraryHeaderBit| replace:: ```` +.. |StandardLibraryHeaderBit| replace:: ```` Defined in header |KokkosBitManipulation|_ which is included from ```` -Provides function templates from the standard library header |StandarLibraryHeaderBit|_ (since C++20). +Provides function templates from the standard library header |StandardLibraryHeaderBit|_ (since C++20). Bit manipulation function templates are defined in the ``Kokkos::`` namespace since Kokkos 4.1 diff --git a/docs/source/API/core/policies/TeamHandleConcept.rst b/docs/source/API/core/policies/TeamHandleConcept.rst index 75e83fe5d..b95976b2d 100644 --- a/docs/source/API/core/policies/TeamHandleConcept.rst +++ b/docs/source/API/core/policies/TeamHandleConcept.rst @@ -134,7 +134,7 @@ Description .. cppkokkos:kokkosinlinefunction:: template< typename ReducerType> void team_reduce( ReducerType const & reducer ) const noexcept; - Performs a reduction accross all members of the team as specified by ``reducer``. ``ReducerType`` must meet the concept of ``Kokkos::Reducer``. + Performs a reduction across all members of the team as specified by ``reducer``. ``ReducerType`` must meet the concept of ``Kokkos::Reducer``. .. cppkokkos:kokkosinlinefunction:: template< typename T > T team_scan( T const & value , T * const global = 0 ) const noexcept; @@ -150,7 +150,7 @@ Examples .. code-block:: cpp - typedef TeamPolciy<...> policy_type; + typedef TeamPolicy<...> policy_type; parallel_for(policy_type(N,TEAM_SIZE).set_scratch_size(PerTeam(0,4096)), KOKKOS_LAMBDA (const typename policy_type::member_type& team_handle) { int ts = team_handle.team_size(); // returns TEAM_SIZE diff --git a/docs/source/API/core/spaces/partition_space.rst b/docs/source/API/core/spaces/partition_space.rst index aba90e333..c4f3abe47 100644 --- a/docs/source/API/core/spaces/partition_space.rst +++ b/docs/source/API/core/spaces/partition_space.rst @@ -23,7 +23,7 @@ Interface .. cppkokkos:function:: template std::vector partition_space(const ExecSpace& space, Args...args); -.. cppkokkos:function:: template std::vector partition_space(const ExecSpace& space, std::vector const& weigths); +.. cppkokkos:function:: template std::vector partition_space(const ExecSpace& space, std::vector const& weights); Creates new execution space instances which dispatch to the same underlying hardware resources as an existing execution space instance. diff --git a/docs/source/API/core/utilities/experimental.md b/docs/source/API/core/utilities/experimental.md index f02981e06..84b90a41b 100644 --- a/docs/source/API/core/utilities/experimental.md +++ b/docs/source/API/core/utilities/experimental.md @@ -11,4 +11,4 @@ namespace Kokkos { } ``` -Namespace inside main `Kokkos` namespace that contains features that are not yet part of the public API. Anything contained might be subject to any change, removal, or extension without anouncement. No guarantees are given. +Namespace inside main `Kokkos` namespace that contains features that are not yet part of the public API. Anything contained might be subject to any change, removal, or extension without announcement. No guarantees are given. diff --git a/docs/source/API/core/utilities/min_max_clamp.rst b/docs/source/API/core/utilities/min_max_clamp.rst index f752e23cd..9f86ce334 100644 --- a/docs/source/API/core/utilities/min_max_clamp.rst +++ b/docs/source/API/core/utilities/min_max_clamp.rst @@ -4,13 +4,13 @@ Minimum/maximum operations .. role:: cppkokkos(code) :language: cpp -.. _StandarLibraryHeaderAlgorithm: https://en.cppreference.com/w/cpp/header/algorithm +.. _StandardLibraryHeaderAlgorithm: https://en.cppreference.com/w/cpp/header/algorithm -.. |StandarLibraryHeaderAlgorithm| replace:: ```` +.. |StandardLibraryHeaderAlgorithm| replace:: ```` Defined in header ```` -Provides minimum/maximum and related operations from the standard library header |StandarLibraryHeaderAlgorithm|_. +Provides minimum/maximum and related operations from the standard library header |StandardLibraryHeaderAlgorithm|_. The min/max and clamp function templates are defined in the ``Kokkos::`` namespace since Kokkos 3.7 diff --git a/docs/source/ProgrammingGuide/Atomic-Operations.md b/docs/source/ProgrammingGuide/Atomic-Operations.md index 9347f823c..14db6181e 100644 --- a/docs/source/ProgrammingGuide/Atomic-Operations.md +++ b/docs/source/ProgrammingGuide/Atomic-Operations.md @@ -84,12 +84,12 @@ void compute_force(View neighbours, View values) { There are also atomic operations which return the old or the new value. They follow the [`atomic_fetch_[op]`](../API/core/atomics/atomic_fetch_op) and [`atomic_[op]_fetch`](../API/core/atomics/atomic_op_fetch) naming scheme. For example if one would want to find all the indices of negative values in an array and store them in a list this would be the algorithm: ```c++ -void find_indicies(View indicies, View values) { +void find_indices(View indices, View values) { View count("Count"); - parallel_for("FindIndicies", values.extent(0), KOKKOS_LAMBDA(const int i) { + parallel_for("FindIndices", values.extent(0), KOKKOS_LAMBDA(const int i) { if(values(i) < 0) { int index = atomic_fetch_add(&count(),1); - indicies(index) = i; + indices(index) = i; } }); } diff --git a/docs/source/ProgrammingGuide/Compatibility.md b/docs/source/ProgrammingGuide/Compatibility.md index b7251d936..ac8f4dcc9 100644 --- a/docs/source/ProgrammingGuide/Compatibility.md +++ b/docs/source/ProgrammingGuide/Compatibility.md @@ -38,7 +38,7 @@ This namespace houses experimental features that are not yet ready for prime tim User defined macros can be particularly problematic, as they change what is lexically seen by the compiler and do not obey the language scoping rules. They could interfere with variable names, functions, etc., including private ones used in Kokkos and other libraries. -In order to minimize the risk of collisons, user defined macros should be prefaced with `MYPROJECT_` (or a similar way to disambiguate them) and be in all caps (this informs code readers that macros don't obey the usual syntactic and semantic rules of C++). +In order to minimize the risk of collisions, user defined macros should be prefaced with `MYPROJECT_` (or a similar way to disambiguate them) and be in all caps (this informs code readers that macros don't obey the usual syntactic and semantic rules of C++). ## C++ Compatibility diff --git a/docs/source/ProgrammingGuide/Kokkos-and-Virtual-Functions.md b/docs/source/ProgrammingGuide/Kokkos-and-Virtual-Functions.md index d61189a18..6e275905e 100644 --- a/docs/source/ProgrammingGuide/Kokkos-and-Virtual-Functions.md +++ b/docs/source/ProgrammingGuide/Kokkos-and-Virtual-Functions.md @@ -62,7 +62,7 @@ The problem here is that we are constructing the class on the Host. If we were c ```c++ Base* hostInstance = new Derived(); // allocate and initialize host Base* deviceInstance; // cudaMalloc'd to allocate -cudaMemcpy(deviceInstance, hostInstance); // to initialize the deivce +cudaMemcpy(deviceInstance, hostInstance); // to initialize the device Kokkos::parallel_for(... { // use deviceInstance }); @@ -92,7 +92,7 @@ The first problem people run into with this is that they want to initialize some Base* hostInstance = new Derived(); // allocate and initialize host hostInstance->setAField(someHostValue); Base* deviceInstance; // cudaMalloc'd to allocate -cudaMemcpy(deviceInstance, hostInstance); // to initialize the deivce +cudaMemcpy(deviceInstance, hostInstance); // to initialize the device Kokkos::parallel_for(... { // use deviceInstance }); @@ -122,7 +122,7 @@ This is the solution that the code teams we have talked to have said is the most ## But what if I do not really need the V-Tables on the device side? Consider the following example which calls the `virtual Bar()` on the device from a pointer of derived class type. -One might think this should work because no V-Table lookup on the device is neccessary. +One might think this should work because no V-Table lookup on the device is necessary. ```c++ #include #include diff --git a/docs/source/ProgrammingGuide/ProgrammingModel.md b/docs/source/ProgrammingGuide/ProgrammingModel.md index 155d0f452..25cd8d5a6 100644 --- a/docs/source/ProgrammingGuide/ProgrammingModel.md +++ b/docs/source/ProgrammingGuide/ProgrammingModel.md @@ -47,7 +47,7 @@ Memory Spaces are the places _Where_ data resides. They specify physical locatio ## 3.5 Memory Layout -Layouts express the _mapping_ from logical (or algorithmical) indices to address offset for a data allocation. By adopting appropriate layouts for memory structures, an application can optimise data access patterns in a given algorithm. If an implementation provides polymorphic layouts (i.e. a data structure can be instantiated at compile or runtime with different layouts), an architecture dependent optimisation can be performed. +Layouts express the _mapping_ from logical (or algorithmically) indices to address offset for a data allocation. By adopting appropriate layouts for memory structures, an application can optimise data access patterns in a given algorithm. If an implementation provides polymorphic layouts (i.e. a data structure can be instantiated at compile or runtime with different layouts), an architecture dependent optimisation can be performed. ## 3.6 Memory Traits diff --git a/docs/source/ProgrammingGuide/SIMD.md b/docs/source/ProgrammingGuide/SIMD.md index a2f37f50a..f6417da1c 100644 --- a/docs/source/ProgrammingGuide/SIMD.md +++ b/docs/source/ProgrammingGuide/SIMD.md @@ -19,7 +19,7 @@ The vendor-specific portions are abstracted away from user code through template The reason that SIMD types are so effective at producing high-performance code is that users are directly expressing what the vector parallelism is that they would like, and doing so in a way that is guaranteed to generate the vector instructions they expect. When using SIMD types, the compiler cannot fail to auto-vectorize, because auto-vectorization is not part of the picture. Users are more clearly able to reason about the available parallelism in their code in ways that an auto-vectorizer is almost never able to do. -By allowing users to have direct control of how vectorization is done while protecting them from both vendor lock-in and the odd quirks of different vendor instruction sets, SIMD types allow users to write performance portable code accross CPUs and also GPUs. +By allowing users to have direct control of how vectorization is done while protecting them from both vendor lock-in and the odd quirks of different vendor instruction sets, SIMD types allow users to write performance portable code across CPUs and also GPUs. ## An Example diff --git a/docs/source/known-issues.rst b/docs/source/known-issues.rst index af2cf092f..4360817d2 100644 --- a/docs/source/known-issues.rst +++ b/docs/source/known-issues.rst @@ -92,7 +92,7 @@ SYCL Mathematical functions ====================== -- Compatibilty issue with using-directives and mathematical functions: +- Compatibility issue with using-directives and mathematical functions: .. code-block:: cpp diff --git a/docs/source/quick_start.rst b/docs/source/quick_start.rst index 5c0fd4aa6..fae69d77f 100644 --- a/docs/source/quick_start.rst +++ b/docs/source/quick_start.rst @@ -83,4 +83,4 @@ Building and Linking a Kokkos "Hello World" Getting Help ------------ -If you need addtional help getting started, please join the `Kokkos Slack Channel `_. Here are `sign up details `_. Joining Kokkos Slack is the on ramp for becoming a project contributor. +If you need additional help getting started, please join the `Kokkos Slack Channel `_. Here are `sign up details `_. Joining Kokkos Slack is the on ramp for becoming a project contributor.