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-core builds 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 build gpu_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_vector is available and gpu_vector is 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=ON together with CLIO_GPU_CLANG=ON. nvcc cannot compile device coroutines, so clang must be the CUDA compiler. Without the clang flag the configure step prints that gpu_vector is disabled and builds nothing for it.
  • CLIO_CORE_ENABLE_SYCL=ON with the oneAPI compiler (icpx -fsycl). The SYCL device compiler is clang-based, so no extra flag is needed.
  • CLIO_CORE_ENABLE_ROCM=ON on AMD (HIP platform not nvidia). The headers are reachable, but every test and benchmark under the adapter guards on CUDA or SYCL, so a ROCm build produces no gpu_vector workload yet.

CUDA with clang

shell
$ 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-failure

The 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)

shell
$ 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

shell
$ cmake --preset release -DCLIO_CORE_ENABLE_TESTS=ON
$ cmake --build build -j"$(nproc)"
$ ctest --test-dir build -L cpu_vector --output-on-failure

cpu_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: header clio_cte/cpu_vector/cpu_vector.h, namespace clio::cte::cpu_vector, build-tree target clio::cte::cpu_vector.
  • gpu_vector: header clio_cte/gpu_vector/gpu_vector.h (host side; it includes device_vector.h for the kernel side), namespace clio::cte::gpu_vector, build-tree target clio::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:

cmake
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.

yaml · clio.yaml
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.