Measure the configuration you will use.
A reproducible record for latency, memory, accuracy, and security assumptions.
For performance evaluation · Source guide · 2394fa5
What the explorer currently shows
The benchmark explorer reports full-slot CKKS bootstrapping restoring 16 net levels at scale 2³⁵ on an AMD Ryzen 9 9950X. It includes C2S-first and S2C-first timings, precision, presets, key/ciphertext modulus bounds. The measurements use Poulpy 0.8.3. Individual iteration records are pending; the supplied summaries cover 20 measured iterations after three warm-ups per configuration. Binary FHE results are not yet available.
The performance guide explains mechanisms and tuning hypotheses. Use it to select candidates, then measure your actual circuit.
Inspect a reproducible learning run
The raw learning-example record contains 20 measured evaluations after three warm-ups, with per-run correctness checks, source and lockfile hashes, compiler/CPU details, parameters, serialized sizes, and the timing boundary. Reproduce it with scripts/measure-example.mjs in the website repository after building the example.
It uses a shared host and a small parameter set with no security rating. Prepared-key size and peak process memory were not measured and are explicitly marked as such. This record shows how to report an experiment; it is not a backend comparison and does not populate the full-scale CKKS explorer.
Define the operation boundary
Measure key generation, key preparation, encoding/encryption, evaluation, and decryption separately. State whether transfers, allocation, thread-pool startup, and preparation are included. Distinguish one-operation latency from throughput across independent ciphertexts.
The client/evaluator example prints evaluation latency and serialized byte counts as a local diagnostic. Its small learning parameters have no security rating and its one timing sample is not a comparative benchmark.
Record enough to reproduce
| Field | Required information |
|---|---|
| Code | Repository, full commit or exact versions, lockfile, command, input generator/seed |
| Machine | Host CPU and accelerator models, host/device memory, OS, driver/runtime versions, instruction sets, power policy, affinity and other load |
| Build | Rust and device compiler versions where applicable, release profile, Cargo features, target flags |
| Workload | Scheme, operation/pipeline, real/complex slot count, input range, batch size |
| Parameters | Ring degree/rank, all ciphertext and evaluation-key widths, limb/decomposition sizes, secret/error distributions |
| Security | Target, estimator revision, attack assumptions, additional construction assumptions |
| Accuracy | Required tolerance and measured error; bootstrap failure/correctness criteria where relevant |
| Timing | Warm-up, independent repetitions, median and defined spread statistic; included/excluded transfers, device synchronization, and other work |
| Memory | Serialized and prepared key bytes, ciphertext bytes, scratch reservation, peak host and device memory |
| Parallelism | Backend, host threads, device execution configuration where applicable, concurrent operations, scheduling configuration |
Use the same accuracy and security goals for a cross-library comparison, and disclose differences in algorithms, packing, and preparation. A transform-count argument alone is not a runtime result.
Run the maintained tools
From the pinned checkout:
cargo bench --locked -p poulpy-bench --bench vec_znx --features hal-benchThis is a primitive benchmark, not an application estimate. The benchmark crate documents additional targets. Thread tuning provides a sweep for the chosen hardware.
Keep raw output with the configuration record. Publish measured comparisons only when their records are available, and repeat measurement after changing parameters, compiler, backend, or source revision.