Find the supported path.
A source-referenced map of Poulpy functionality, hardware, and external integrations.
For library evaluation · Source guide · 2394fa5
Scope and version
This matrix describes the pinned source-guide baseline. Native means an implementation and public API are present in that source. It does not imply a security certification or a performance guarantee. Published crate documentation can lag this baseline.
| Capability | Status | Entry point and scope |
|---|---|---|
| Approximate packed real/complex arithmetic | Native CKKS | CKKS: addition, multiplication, rotations, conjugation, polynomial and linear-map evaluation |
| CKKS refresh and functional bootstrapping | Native CKKS | Bootstrapping: pipeline and lookup-table input contracts |
| PaCo and SHIP | Native, specialized constructions | PaCo and SHIP: read their additional secret-distribution and precision assumptions |
| Boolean, lookup-table and integer circuits | Native Binary FHE | Binary FHE: blind rotation, circuit bootstrapping, BDD arithmetic |
| LWE/GLWE key switching and conversions | Native core | Core operations; these are not a blanket promise of conversion between arbitrary schemes |
| BFV/BGV and general CKKS ↔ Binary FHE bridges | Architectural direction; no runnable scheme API established by this guide | Shared Torus arithmetic makes reuse possible. Verify a specific conversion API and its contract before designing around it. |
| GPU execution | Backend in active development | Uses the hardware-independent backend architecture; see Hardware targets |
| Other hardware targets | Backend extension points | Backend freedom: implement the HAL and specialize operations, layouts, and scheduling for the target |
| Browser and Node use | External integration | Squid wraps Binary FHE; its supported types and operations are defined by that project |
| Compiler integration | External integration | HEIR: a Poulpy target; check its supported lowering path and generated-code dependencies |
Available CPU families
Poulpy’s backend architecture spans hardware targets. The table below documents CPU implementations at the pinned source revision; a GPU backend is also in active development.
| Hardware | Implementation | Practical constraint |
|---|---|---|
| Portable CPU | FFT64Ref, NTT4x30Ref | Useful baseline; no SIMD feature requirement |
| x86 AVX2/FMA | FFT64 and NTT4x30 | Cargo features and target CPU instructions must both be enabled |
| x86 AVX-512 | FFT64 and NTT4x30 | Requires the corresponding CPU instructions |
| x86 AVX-512 IFMA | NTT3x42 | Requires IFMA and the documented additional target features |
| AArch64 NEON | FFT64 and NTT4x30 | AArch64 build target; inspect backend-specific assumptions |
| Several CPU cores | Rayon variants | Benefits depend on the operation, shape, and thread pool |
The backend guide gives concrete types and flags. Its scope is arithmetic support; it does not establish ciphertext-format interoperability with other FHE libraries.
Assess fit before committing
For a numerical workload, establish its input range, acceptable approximation, packing, and depth. For integer circuits, check available widths, signedness, overflow behavior, and operation semantics in the API and example. For protocol requirements such as threshold keys, multi-party operation, or importing another library’s ciphertexts, obtain a specific implementation reference: this matrix does not establish support for them.
Continue with Parameters, Security, and a standalone application. Use the measurement guide for cost estimates on your hardware.