From 1ac2d3bebd191f4b9a490992236f80cb6aadf524 Mon Sep 17 00:00:00 2001 From: Victoriya Fedotova Date: Wed, 23 Oct 2024 02:53:51 -0700 Subject: [PATCH] Replace oneDAL with |short_name| to align with other .rst files --- docs/source/contribution/cpu_features.rst | 38 +++++++++++------------ docs/source/contribution/threading.rst | 26 ++++++++-------- 2 files changed, 32 insertions(+), 32 deletions(-) diff --git a/docs/source/contribution/cpu_features.rst b/docs/source/contribution/cpu_features.rst index 030803fc1b7..6b3daa44d93 100644 --- a/docs/source/contribution/cpu_features.rst +++ b/docs/source/contribution/cpu_features.rst @@ -19,15 +19,15 @@ CPU Features Dispatching ^^^^^^^^^^^^^^^^^^^^^^^^ -For each algorithm oneDAL provides several code paths for x86-64-compatibe instruction +For each algorithm |short_name| provides several code paths for x86-64-compatibe instruction set architectures. Following architectures are currently supported: -- Intel\ |reg| Streaming SIMD Extensions 2 (Intel\ |reg| SSE2) -- Intel\ |reg| Streaming SIMD Extensions 4.2 (Intel\ |reg| SSE4.2) -- Intel\ |reg| Advanced Vector Extensions 2 (Intel\ |reg| AVX2) -- Intel\ |reg| Advanced Vector Extensions 512 (Intel\ |reg| AVX-512) +- Intel\ |reg|\ Streaming SIMD Extensions 2 (Intel\ |reg|\ SSE2) +- Intel\ |reg|\ Streaming SIMD Extensions 4.2 (Intel\ |reg|\ SSE4.2) +- Intel\ |reg|\ Advanced Vector Extensions 2 (Intel\ |reg|\ AVX2) +- Intel\ |reg|\ Advanced Vector Extensions 512 (Intel\ |reg|\ AVX-512) The particular code path is chosen at runtime based on the underlying hardware characteristics. @@ -36,9 +36,9 @@ This chapter describes how the code is organized to support this variety of inst Algorithm Implementation Options ******************************** -In addition to the instruction set architectures, an algorithm in oneDAL may have various +In addition to the instruction set architectures, an algorithm in |short_name| may have various implementation options. Below is a description of these options to help you better understand -the oneDAL code structure and conventions. +the |short_name| code structure and conventions. Computational Tasks ------------------- @@ -66,14 +66,14 @@ methods for algorithm training and inference. Computational Modes ------------------- -oneDAL can provide several computaional modes for an algorithm. +|short_name| can provide several computaional modes for an algorithm. See `Computaional Modes `_ chapter for details. Folders and Files ***************** -Suppose that you are working on some algorithm ``Abc`` in oneDAL. +Suppose that you are working on some algorithm ``Abc`` in |short_name|. The part of the implementation of this algorithms that is running on CPU should be located in `cpp/daal/src/algorithms/abc` folder. @@ -166,14 +166,14 @@ instruction set specific code. The implementation is located in the file `abc_cl .. include:: ../includes/cpu_features/abc-classification-train-method1-impl.rst Although the implementation of the ``method1`` does not contain any instruction set specific code, it is -expected that the developers leverage SIMD related macros available in oneDAL. +expected that the developers leverage SIMD related macros available in |short_name|. For example, ``PRAGMA_IVDEP``, ``PRAGMA_VECTOR_ALWAYS``, ``PRAGMA_VECTOR_ALIGNED`` and others pragmas defined in `service_defines.h `_. This will guide the compiler to generate more efficient code for the target architecture. Consider that the implementation of the ``method2`` for the same algorithm will be different and will contain AVX-512-specific code located in ``cpuSpecificCode`` function. Note that all the compiler-specific code should -be placed under compiler-specific defines. For example, the Intel\ |reg| oneAPI DPC++/C++ Compiler specific code +be placed under compiler-specific defines. For example, the Intel\ |reg|\ oneAPI DPC++/C++ Compiler specific code should be placed under ``DAAL_INTEL_CPP_COMPILER`` define. All the CPU-specific code should be placed under CPU-specific defines. For example, the AVX-512 specific code should be placed under ``__CPUID__(DAAL_CPU) == __avx512__``. @@ -205,14 +205,14 @@ The values for ``DAAL_FPTYPE`` macro replacement are ``float`` and ``double``, r The values for ``cpu`` file name part replacement are: -- ``nrh`` for Intel\ |reg| SSE2 architecture, which stands for Northwood, -- ``neh`` for Intel\ |reg| SSE4.2 architecture, which stands for Nehalem, -- ``hsw`` for Intel\ |reg| AVX2 architecture, which stands for Haswell, -- ``skx`` for Intel\ |reg| AVX-512 architecture, which stands for Skylake-X. +- ``nrh`` for Intel\ |reg|\ SSE2 architecture, which stands for Northwood, +- ``neh`` for Intel\ |reg|\ SSE4.2 architecture, which stands for Nehalem, +- ``hsw`` for Intel\ |reg|\ AVX2 architecture, which stands for Haswell, +- ``skx`` for Intel\ |reg|\ AVX-512 architecture, which stands for Skylake-X. The values for ``DAAL_CPU`` macro replacement are: -- ``__sse2__`` for Intel\ |reg| SSE2 architecture, -- ``__sse42__`` for Intel\ |reg| SSE4.2 architecture, -- ``__avx2__`` for Intel\ |reg| AVX2 architecture, -- ``__avx512__`` for Intel\ |reg| AVX-512 architecture. +- ``__sse2__`` for Intel\ |reg|\ SSE2 architecture, +- ``__sse42__`` for Intel\ |reg|\ SSE4.2 architecture, +- ``__avx2__`` for Intel\ |reg|\ AVX2 architecture, +- ``__avx512__`` for Intel\ |reg|\ AVX-512 architecture. diff --git a/docs/source/contribution/threading.rst b/docs/source/contribution/threading.rst index cd1acd84e95..6233bc0e813 100644 --- a/docs/source/contribution/threading.rst +++ b/docs/source/contribution/threading.rst @@ -19,20 +19,20 @@ Threading Layer ^^^^^^^^^^^^^^^ -oneDAL uses Intel\ |reg|\ oneAPI Threading Building Blocks (Intel\ |reg|\ oneTBB) to do parallel +|short_name| uses Intel\ |reg|\ oneAPI Threading Building Blocks (Intel\ |reg|\ oneTBB) to do parallel computations on CPU. -But oneTBB is not used in the code of oneDAL algorithms directly. The algorithms rather +But oneTBB is not used in the code of |short_name| algorithms directly. The algorithms rather use custom primitives that either wrap oneTBB functionality or are in-house developed. -Those primitives form oneDAL's threading layer. +Those primitives form |short_name|'s threading layer. This is done in order not to be dependent on possible oneTBB API changes and even on the particular threading technology like oneTBB, C++11 standard threads, etc. The API of the layer is defined in `threading.h `_. -Please be aware that the threading API is not a part of oneDAL product API. -This is the product internal API that aimed to be used only by oneDAL developers, and can be changed at any time +Please be aware that the threading API is not a part of |short_name| product API. +This is the product internal API that aimed to be used only by |short_name| developers, and can be changed at any time without any prior notification. This chapter describes common parallel patterns and primitives of the threading layer. @@ -46,7 +46,7 @@ Here is a variant of sequential implementation: .. include:: ../includes/threading/sum-sequential.rst -There are several options available in the threading layer of oneDAL to let the iterations of this code +There are several options available in the threading layer of |short_name| to let the iterations of this code run in parallel. One of the options is to use ``daal::threader_for`` as shown here: @@ -59,10 +59,10 @@ Blocking -------- To have more control over the parallel execution and to increase -`cache locality `_ oneDAL usually splits +`cache locality `_ |short_name| usually splits the data into blocks and then processes those blocks in parallel. -This code shows how a typical parallel loop in oneDAL looks like: +This code shows how a typical parallel loop in |short_name| looks like: .. include:: ../includes/threading/sum-parallel-by-blocks.rst @@ -92,7 +92,7 @@ Checking the status right after the initialization code won't show the allocatio because oneTBB uses lazy evaluation and the lambda function passed to the constructor of the TLS is evaluated on first use of the thread-local storage (TLS). -There are several options available in the threading layer of oneDAL to compute the partial +There are several options available in the threading layer of |short_name| to compute the partial dot product results at each thread. One of the options is to use the already mentioned ``daal::threader_for`` and blocking approach as shown here: @@ -126,7 +126,7 @@ is more performant to use predefined mapping of the loop's iterations to threads This is what static work scheduling does. ``daal::static_threader_for`` and ``daal::static_tls`` allow implementation of static -work scheduling within oneDAL. +work scheduling within |short_name|. Here is a variant of parallel dot product computation with static scheduling: @@ -135,7 +135,7 @@ Here is a variant of parallel dot product computation with static scheduling: Nested Parallelism ****************** -oneDAL supports nested parallel loops. +|short_name| supports nested parallel loops. It is important to know that: "when a parallel construct calls another parallel construct, a thread can obtain a task @@ -154,13 +154,13 @@ oneTBB provides ways to isolate execution of a parallel construct, for its tasks to not interfere with other simultaneously running tasks. Those options are preferred when the parallel loops are initially written as nested. -But in oneDAL there are cases when one parallel algorithm, the outer one, +But in |short_name| there are cases when one parallel algorithm, the outer one, calls another parallel algorithm, the inner one, within a parallel region. The inner algorithm in this case can also be called solely, without additional nesting. And we do not always want to make it isolated. -For the cases like that, oneDAL provides ``daal::ls``. Its ``local()`` method always +For the cases like that, |short_name| provides ``daal::ls``. Its ``local()`` method always returns the same value for the same thread, regardless of the nested execution: .. include:: ../includes/threading/nested-parallel-ls.rst