Docs · Memory expansion
Install memory expansion.
cpu_vector is header-only and part of every CLIO Core build. gpu_vector is header-only too, but its device verbs are C++20 coroutines, so it is only built when the GPU toolchain can compile them. Both are C++; there is no Python binding of the vectors in the wheel.
- cpu_vector
- every build
- gpu_vector CUDA
- CLIO_CORE_ENABLE_CUDA=ON CLIO_GPU_CLANG=ON
- gpu_vector SYCL
- CLIO_CORE_ENABLE_SYCL=ON
- Headers
- include/clio_cte/{cpu_vector,gpu_vector}/
What each install contains
- pip.
pip install iowarp-corebuilds a CPU-only runtime with no C++ headers, so neither vector is usable from it. The GPU wheel variants (iowarp-core-cuda12,iowarp-core-rocm6,iowarp-core-sycl) install the same Python package with GPU support in the runtime; they ship no headers either, and the CUDA variant is compiled with nvcc, which does not buildgpu_vector. For paged data from Python use clio-ml, whose datasets are paged vectors underneath. - conda, Spack, packages. These install the C++ libraries and headers from a CPU build, so
cpu_vectoris available andgpu_vectoris not. - Source. Needed for
gpu_vector. See below.
Build from source
Follow the general install page for the platform prerequisites, then configure with the GPU options. The adapter CMake file builds gpu_vector when one of these holds:
CLIO_CORE_ENABLE_CUDA=ONtogether withCLIO_GPU_CLANG=ON. nvcc cannot compile device coroutines, so clang must be the CUDA compiler. Without the clang flag the configure step prints thatgpu_vectoris disabled and builds nothing for it.CLIO_CORE_ENABLE_SYCL=ONwith the oneAPI compiler (icpx -fsycl). The SYCL device compiler is clang-based, so no extra flag is needed.CLIO_CORE_ENABLE_ROCM=ONon AMD (HIP platform notnvidia). The headers are reachable, but every test and benchmark under the adapter guards on CUDA or SYCL, so a ROCm build produces nogpu_vectorworkload yet.
CUDA with clang
$ git clone --recurse-submodules https://github.com/iowarp/clio-core.git
$ cd clio-core
$ cmake -S . -B build-gv -G Ninja \
-DCMAKE_BUILD_TYPE=Release \
-DCLIO_CORE_ENABLE_CUDA=ON -DCLIO_GPU_CLANG=ON \
-DCLIO_CORE_ENABLE_TESTS=ON
$ cmake --build build-gv -j"$(nproc)"
$ ctest --test-dir build-gv -L gpu_vector --output-on-failureThe cuda-release preset in CMakePresets.json enables CUDA; add -DCLIO_GPU_CLANG=ON to it, or configure by hand as above. Tests are registered under the labels cte, gpu and gpu_vector.
SYCL (Intel GPUs)
$ cmake -S . -B build-sycl -G Ninja \
-DCMAKE_C_COMPILER=icx -DCMAKE_CXX_COMPILER=icpx \
-DCLIO_CORE_ENABLE_SYCL=ON -DCLIO_CORE_ENABLE_TESTS=ON
$ cmake --build build-sycl -j"$(nproc)"The SYCL kernels for the vector live in context-transfer-engine/adapter/gpu_vector/test/sycl, in their own directory because SYCL kernel bodies are lambdas rather than __global__ functions.
CPU only
$ cmake --preset release -DCLIO_CORE_ENABLE_TESTS=ON
$ cmake --build build -j"$(nproc)"
$ ctest --test-dir build -L cpu_vector --output-on-failurecpu_vector is built in every configuration. Its test, cte_cpu_vector, starts a runtime in-process with a RAM tier.
Headers and CMake targets
cpu_vector: headerclio_cte/cpu_vector/cpu_vector.h, namespaceclio::cte::cpu_vector, build-tree targetclio::cte::cpu_vector.gpu_vector: headerclio_cte/gpu_vector/gpu_vector.h(host side; it includesdevice_vector.hfor the kernel side), namespaceclio::cte::gpu_vector, build-tree targetclio::cte::gpu_vector.
Both targets are INTERFACE libraries that add the include directory and link clio_cte_core_client and clio_cte_checkpoint_client. They exist in the CLIO Core build tree, and the adapter's own tests and benchmarks link them. The install step copies the headers into include/ but does not export the two interface targets, so a project built against an installed tree includes the headers and links the exported client targets itself:
find_package(clio-core CONFIG REQUIRED) # exports clio::cte::core_client
add_executable(my_vector_app main.cc)
target_link_libraries(my_vector_app clio::cte::core_client)
# Vector::Copy needs the checkpoint client as well. Its module package is
# installed next to clio_cte_core; it is not pulled in by the umbrella package.A GPU program also links the runtime's GPU library and the vendor runtime. The adapter's CUDA tests link clio_run_cxx, clio_run_cxx_gpu, clio_cte_core_client, clio_cte_core_runtime, clio::cte::gpu_vector and ctp::cuda_cxx; the copy test adds clio_cte_checkpoint_client and clio_cte_checkpoint_runtime. Building inside the CLIO Core tree, with add_subdirectory or as an adapter, is the path the project itself exercises.
Runtime configuration
The runtime's compose must contain a clio_cte_core pool with at least one storage tier; without a tier the first writeback has nowhere to land and never completes. The default configuration qualifies. For GPU kernels, set gpu.queue_depth above the number of blocks that will have transfers in flight; the default is 16.
runtime:
num_threads: 4
queue_depth: 1024
gpu:
queue_depth: 64
compose:
- mod_name: clio_cte_core
pool_name: clio_cte
pool_query: local
pool_id: 512.0
storage:
- path: "ram::vector_dram"
bdev_type: "ram"
capacity_limit: "1GB"
score: 1.0
dpe:
dpe_type: "max_bw"Check the install
From a build tree with tests enabled, the two test labels above are the check. Without tests, compile the cpu_vector example on the usage page and run it with CLIO_SERVER_CONF pointing at a file like the one above. It exits 0 when every element reads back.
Where to go next
- Usage: the host example and the CUDA kernel.
- API reference: constructors, verbs, host methods, configuration.