mirror of
https://github.com/luxfhe/torus.git
synced 2026-10-30 17:07:26 +00:00
zeekay
b832ba2c39
Forked from upstream concrete (BSD-3-Clause-Clear, © 2024 ZAMA) at HEAD
ecb729bb. Modifications copyright © 2026 Lux Industries Inc.
Rebranding scope:
- Python module concrete → torus (across frontends/torus-python)
- Rust module concrete-* → torus-* (across frontends/torus-rust)
- MLIR dialect concretelang → toruslang (across compilers/torus-compiler)
- Compiler optimizer concrete-optimizer → torus-optimizer
- Backend concrete-cpu / concrete-cuda → torus-cpu / torus-cuda
- Wire protocol concrete-protocol → torus-protocol
- Parameter-curves concrete-security-curves-* → torus-security-curves-*
- Public symbols concretelib → toruslib, ConcreteLang → TorusLang
- URLs github.com/zama-ai/concrete → github.com/luxfhe/torus
- URLs docs.zama.ai/concrete → docs.luxfhe.com/torus
Legal compliance:
- LICENSE.txt retains original Copyright © 2024 ZAMA verbatim (§1-§2)
- LICENSE.txt adds modifications copyright © 2026 Lux Industries Inc.
- §3 endorsement clause: Torus is marketed exclusively as a Lux product;
no Zama name used in README, docs, or marketing
- NOTICE file provides factual attribution per legal best practice
(not endorsement; required by upstream BSD-3-Clause-Clear)
README + NOTICE rewritten from scratch with Lux brand:
- Quick-start in Python (torus.fhe)
- Architecture diagram showing the gen-1 vtbl integration path
(luxcpp/gpu → lux-private/gpu-kernels for CUDA/Metal/WebGPU)
- Scheme coverage table: TFHE (luxfi/fhe), CKKS/BGV/BFV (luxfi/lattice)
- Lux FHE family table: Torus / TorusVM / TorusEVM / TorusML / TorusNet
Known limitations (phase-2A scope):
- PyPI package torus-fhe not yet published; the torus Python module
is renamed structurally but pip-installable distribution is a
follow-up (Phase 2A.1)
- MLIR dialect rename is text-level; the compiler-internal LLVM
rebuild (concrete-compiler-internal-llvm-project submodule) is
structural and works; tablegen files renamed concrete→torus but the
generated .inc files in the source tree will regenerate at build
time
- backends/torus-cuda/implementation/ is an upstream submodule
pointer to the tfhe-rs source (not fetched in the staging clone);
the CUDA backend body is delivered out-of-tree
- ~100 test-fixture variable names like concrete_encoded_sample
retain "concrete" as a math term (vs symbolic); these are inside
tests/, not the public API; cleanup is a follow-up commit
- 295 Python `from concrete import ...` residuals in luxfhe/ml-sdk
consumer remain; that repo's import update is Phase 2B
This commit is the seed for the luxfhe/torus repo. Push as the first
commit to a fresh GitHub repo; do not re-import upstream Zama git
history.
2.8 KiB
2.8 KiB
Reducing the amount of table lookups
This guide teaches how to improve the execution time of Torus circuits by reducing the amount of table lookups.
Reducing the amount of table lookups is probably the most complicated guide in this section as it's not automated. The idea is to use mathematical properties of operations to reduce the amount of table lookups needed to achieve the result.
One great example is in adding big integers in bitmap representation. Here is the basic implementation:
def add_bitmaps(x, y):
result = fhe.zeros((N,))
carry = 0
addition = x + y
for i in range(N):
addition_and_carry = addition[i] + carry
carry = addition_and_carry >> 1
result[i] = addition_and_carry % 2
return result
There are two table lookups within the loop body, one for >> and one for %.
This implementation is not optimal though, since the same output can be achieved with just a single table lookup:
def add_bitmaps(x, y):
result = fhe.zeros((N,))
carry = 0
addition = x + y
for i in range(N):
addition_and_carry = addition[i] + carry
carry = addition_and_carry >> 1
result[i] = addition_and_carry - (carry * 2)
return result
It was possible to do this because the original operations had a mathematical equivalence with the optimized operations and optimized operations achieved the same output with less table lookups!
Here is the full code example and some numbers for this optimization:
import numpy as np
from torus import fhe
N = 32
def add_bitmaps_naive(x, y):
result = fhe.zeros((N,))
carry = 0
addition = x + y
for i in range(N):
addition_and_carry = addition[i] + carry
carry = addition_and_carry >= 2
result[i] = addition_and_carry % 2
return result
def add_bitmaps_optimized(x, y):
result = fhe.zeros((N,))
carry = 0
addition = x + y
for i in range(N):
addition_and_carry = addition[i] + carry
carry = addition_and_carry >> 1
result[i] = addition_and_carry - (carry * 2)
return result
inputset = fhe.inputset(fhe.tensor[fhe.uint1, N], fhe.tensor[fhe.uint1, N])
for (name, implementation) in [("naive", add_bitmaps_naive), ("optimized", add_bitmaps_optimized)]:
compiler = fhe.Compiler(implementation, {"x": "encrypted", "y": "encrypted"})
circuit = compiler.compile(inputset)
print(
f"{name:>9} implementation "
f"-> {int(circuit.programmable_bootstrap_count)} table lookups "
f"-> {int(circuit.complexity):_} complexity"
)
prints:
naive implementation -> 63 table lookups -> 2_427_170_697 complexity
optimized implementation -> 32 table lookups -> 1_224_206_208 complexity
which is almost half the amount of table lookups and ~2x less complexity for the same operation!