Reader Benefits and Use Cases
This article is for engineers or researchers evaluating the cost of homomorphic encryption inference. After reading, you will:
- Obtain a reproducible performance ledger showing the real-time composition of one hop (in-layer forward + bootstrapping).
- Identify that the true bottleneck lies in domain transforms and key switching, not polynomial multiplication.
- Gain auxiliary information on accuracy, reproducibility, and data consistency to help decide whether to continue optimizing.
Observation Methodology
All figures come from the same experimental environment and are bound to a fixed thread count. Absolute timings across rounds or platforms are not comparable.
| Item | Value / Description |
|---|---|
| Platform | AMD Ryzen 7 9800X3D (8 cores, 16 threads) |
| Thread count | T23_NT |
| Compilation flags | gcc -O2 -fopenmp -DCKKS_N=2048 |
| Chain length | lay compiled at 112; boot compiled at 2100 |
| Comparison method | Interleaved A/B within the same round; absolute timings across rounds are not used |
The Bill for One Hop
| Stage | Time | Criterion | Memory |
|---|---|---|---|
| lay0 | 1920 s | RESULT=PASS | Working set ≈1.0 GB |
| boot0 | 4285 s | BOOT=PASS | Recommended ≥8 GB |
| Total | ≈6205 s (~1.8 h) | — | — |
Bootstrapping is more than twice as expensive as in-layer forward: of the ~1.8 hours per hop, roughly 1.2 hours are spent on boot.
Where the Bootstrapping Money Goes
Breakdown of boot0 by segment (corresponding to the seven-stage pipeline):
| Segment | Time | Share of Boot |
|---|---|---|
| coeff_to_slot | 1688 s | ~39% |
| slot_to_coeff | 1716 s | ~40% |
| sin_fold | ~850 s | ~20% |
| Others | remainder | residual |
| total | 4285.03 s | 100% |
The two domain transform segments together account for ~3400 s, roughly 80% of the bootstrapping time.
The Bottleneck Is Not Computation
The initial optimization instinct is to target the hottest kernels (NTT / polynomial multiplication), but the most frequently invoked kernels are not necessarily the most time-consuming. The real cost comes from:
- A large number of Galois rotations
- A key-switch performed for every rotation
- Key-switch key volume on the order of
nprimes × n × 64 bit, which at a chain length of 2100 is already too large to fit in cache
Therefore, the bottleneck is likely memory bandwidth, not compute throughput. ⚠️ This is an inference, not yet confirmed by microarchitectural profiling.
Precision Ledger
| Object | Result | max|err| |
|---|---|---|
| u0 (lay0, np=16) | PASS 8/8 | 1.2712e-03 |
| u0r112 (after boot refresh) | PASS 8/8 | 1.2706e-03 |
| u26 / u26r112 (chain tail) | PASS 8/8 | 4.4707e-03 ~ 2.2993e-02 |
| u27 (chain tail) | ⚠️ 6/8 | t1h1=3.8216e-02, t3h1=7.9687e-02 (exceeds default tolerance 3e-2) |
Three key points:
- Bootstrapping barely changes numerical values: 1.2712e-03 → 1.2706e-03. Bootstrapping is a "refuel," not an "error correction."
- Error grows with depth: from 1.27e-03 at layer 0 to 2.3e-02 at the chain tail, an increase of roughly one order of magnitude.
- The chain tail has out-of-threshold entries: two of the eight entries in u27 exceed 3e-2, recorded faithfully without adjusting the tolerance.
Reproduction and Data
Bit-Level Reproduction Ledger
- u0 × 8 vs. archive: identical 8 / diff 0
- u0r112 × 8 vs. archive: identical 8 / diff 0
- lay0.out log: 213 / 213 lines, 4 differences, all in timing lines
- boot0.out log: 19 / 19 lines, 1 difference (profile total time)
Data Ledger
- Self-generated weights vs. distributed artifacts: 9/9 byte-identical each
- silu0..25.bin (26 files): 26/26 byte-identical
- Archive manifest self-check: main package 104/104, chain tail 45/45, tool package 6/6
The ~7 GB data package is not distributed with the repository but can be regenerated from the same model, byte-identical.
Security Boundaries
The parameters in this article are at mechanism-validation level (n=2048, 112-prime inner chain, 2100-prime bootstrapping chain), far below 128-bit security and must not be used to protect real data. This article presents an engineering ledger of this specific implementation on a specific machine; it does not claim security strength, performance superiority, or comparison with any other scheme.
Unsolved Problems
- Why are domain transforms so expensive? There is a lack of microarchitectural attribution (cache hits, bandwidth, instruction count) — this is currently the highest-yield analysis direction.
- No "minimum usable chain length" scan has been performed (boot compiled to 2100, actual usage unknown, whether it can be compressed to 1500 is untested).
- There is no closed-loop precision budget (the derivation of per-layer available error from 28 layers backward is missing).
- The share of "memory bandwidth" in single-hop time has not been measured.
Reference Sources
- cnblogs.com: Primary source of measured data in this article. https://www.cnblogs.com/haliuhome/p/23178401
- wavect.io: CKKS scheme applicability context and FHE performance improvement background. https://wavect.io/blog/fully-homomorphic-encryption-practical-2026/
- dualitytech.com: Drivers behind 1,000x–10,000x FHE performance improvements. https://dualitytech.com/blog/homomorphic-encryption-performance-2026/
Next step: If further analysis is needed, it is recommended to prioritize microarchitectural profiling of the domain transform segments (cache hits, bandwidth, instruction count) to verify whether the bottleneck is memory bandwidth — this is currently the highest-yield item among the unsolved problems.