Tangor

PoC of StarPU based Iyokan

CPU build

Tangor builds the CPU path by default. The HOGE/FPGA path remains opt-in via -DUSE_HOGE=ON.

git submodule update --init --recursive
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build -j

Tangor uses thirdparties/cuFHEpp for the TFHEpp checkout at thirdparties/cuFHEpp/thirdparties/TFHEpp. It does not build cuFHEpp's CUDA library for the CPU path.

The default TFHE configuration is Block Binary keys with Subset Keys (USE_BLOCK_BINARY=ON, USE_SUBSET_KEY=ON). Regenerate secret/evaluation keys, encrypted packets, and snapshots after upgrading, since artifacts made with the former defaults are not compatible.

KVSP compatibility

With the default -DTANGOR_BUILD_KVSP_COMPAT=ON, the build produces build/bin/iyokan and build/bin/iyokan-packet in addition to Tangor's native executable. They implement the CLI and cereal packet/archive format expected by KVSP, including plain, tfhe, snapshots, key generation, and packet conversion. Point KVSP at them without changing the KVSP command line:

KVSP_IYOKAN_PATH="$PWD/build/bin/iyokan" \
KVSP_IYOKAN_PACKET_PATH="$PWD/build/bin/iyokan-packet" \
  /path/to/kvsp

The compatibility targets share the checked-out Iyokan frontend sources while linking to Tangor's selected TFHEpp build. This keeps packets, evaluation keys, and snapshots byte-compatible during the scheduler migration. Set -DTANGOR_BUILD_KVSP_COMPAT=OFF for a standalone Tangor-only build. If that checkout is not adjacent to Tangor, CMake fetches the pinned Iyokan frontend (including its submodules) by default; use -DTANGOR_FETCH_IYOKAN_COMPAT=OFF plus TANGOR_IYOKAN_COMPAT_SOURCE_DIR and TANGOR_IYOKAN_COMPAT_THIRDPARTY_DIR for an offline source mirror.

StarPU CPU/GPU execution

Tangor schedules the KVSP gate dependency graph with StarPU. In CUDA mode, StarPU owns each gate's read/write dependency while an event-driven cuFHEpp stream pool evaluates the bootstrap and releases the dependent task only after the result is back on the host. This provides SM-scale CUDA concurrency without one host thread per CUDA stream. ROM/RAM cell refresh uses the same CUDA-pool model. The ROM/RAM FFT CMUX tree remains a TFHEpp CPU operation, matching Iyokan's proven path; TANGOR_EXPERIMENTAL_CUDA_CMUX=1 is retained only for kernel-integration development. No TFHE parameters are changed for runtime compatibility. CPU and CUDA builds both use the split Fourier archive layout, so keys and encrypted ROM/RAM packets are portable across Tangor, Iyokan, and KVSP.

Tangor accepts KVSP's Iyokan CMake cache variables, so KVSP can use Tangor as its source directory without renaming build flags:

git submodule update --init --recursive
cmake -S /path/to/Tangor -B build/Iyokan-avx2 \
  -DCMAKE_BUILD_TYPE=Release \
  -DIYOKAN_ENABLE_CUDA=ON \
  -DIYOKAN_MARCH=x86-64-v3 \
  -DUSE_AVX512=OFF
cmake --build build/Iyokan-avx2 --target iyokan iyokan-packet

To have KVSP build that compatibility target in its normal location:

make -C /path/to/kvsp ENABLE_CUDA=1 IYOKAN_SOURCE=/path/to/Tangor iyokan-avx2

Run with both CPU and GPU resources. For example, this uses 64 CPU workers and two GPUs:

/path/to/kvsp/build/bin/iyokan-avx2 tfhe --enable-gpu --cpu 64 --num-gpu 2 \
  --evalkey eval.key -c 224 -o result.enc --snapshot result.snapshot \
  --blueprint /path/to/kvsp/build/share/kvsp/alexandrite.toml -i fib.enc

--cpu selects the physical StarPU CPU-worker budget, --num-gpu selects CUDA devices, and --enable-gpu enables the CUDA path. Tangor defaults to the physical CPU-core count for CPU-only execution and to all logical CPUs in CUDA mode, where those threads feed independent RAM/ROM preparation and launches. CUDA mode uses StarPU's eager scheduler by default; CPU-only mode uses dmdas. STARPU_SCHED remains an override. The CUDA pools default to two gate streams per SM (TANGOR_GATE_CUDA_WORKERS_PER_GPU) and one RAM-refresh stream per SM (TANGOR_RAM_CUDA_WORKERS_PER_GPU). STARPU_NWORKER_PER_CUDA is left at one worker per device by default because it is a host thread, not a CUDA stream. CPU-only execution uses the same graph without CUDA workers.

StarPU diagnostics

Profiling is off by default. Build with -DTANGOR_STARPU_PROFILE=ON to enable worker/per-task reports and FxT tracing by default. This requires the fxt development package; environment variables still override the defaults, so reports can be redirected or disabled without rebuilding.

The evaluator cannot inspect encrypted termination itself. For KVSP's bundled fib(5) input, a plaintext emulator establishes that 224 cycles are required. Decrypt the resulting packet to confirm f0 = true and x10 = 5:

/path/to/kvsp/build/bin/kvsp dec --cpu alexandrite -k secret.key -i result.enc

StarPU gate scheduling is enabled by default. It can be stated explicitly for reproducible builds:

cmake -S /path/to/Tangor -B build/starpu \
  -DIYOKAN_ENABLE_CUDA=ON -DTANGOR_KVSP_STARPU_GATE_OFFLOAD=ON
build/starpu/bin/iyokan tfhe --enable-gpu --cpu 64 --num-gpu 2 ...

To use a different cuFHEpp checkout:

cmake -S . -B build -DTANGOR_CUFHEPP_SOURCE_DIR=/path/to/cuFHEpp

To override only TFHEpp:

cmake -S . -B build -DTANGOR_TFHEPP_SOURCE_DIR=/path/to/TFHEpp