mirror of
https://github.com/zama-ai/concrete.git
synced 2026-01-08 20:38:06 -05:00
docs(frontend): Fixes on optimization documentation
This commit is contained in:
committed by
Quentin Bourgerie
parent
84a952c005
commit
a5bd59d8e2
@@ -1,7 +1,5 @@
|
||||
# Compatibility
|
||||
|
||||
## Supported operations
|
||||
|
||||
This document lists the operations you can use inside the function that you are compiling.
|
||||
|
||||
{% hint style="info" %}
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
### Enabling dataflow parallelism
|
||||
|
||||
This guide teaches what data parallelism is and how it can improve the execution time of Concrete circuits.
|
||||
This guide explains dataflow parallelism and how it can improve the execution time of **Concrete** circuits.
|
||||
|
||||
Dataflow parallelism is a great feature, especially when the circuit is doing a lot of scalar operations.
|
||||
Dataflow parallelism is particularly useful when the circuit performs computations that are neither completely independent (such as loop/doall parallelism) nor fully dependent (e.g. sequential, non-parallelizable code). In such cases dataflow tasks can execute as soon as their inputs are available and thus minimizing over-synchronization.
|
||||
|
||||
Without dataflow parallelism, circuit is executed operation by operation, like an imperative language. If the operations themselves are not tensorized, loop parallelism would not be utilized and the entire execution would happen in a single thread. Dataflow parallelism changes this by analyzing the operations and their dependencies within the circuit to determine what can be done in parallel and what cannot. Then it distributes the tasks that can be done in parallel to different threads.
|
||||
|
||||
@@ -47,14 +47,14 @@ for dataflow_parallelize in [False, True]:
|
||||
print(f" with dataflow parallelize -> {np.mean(timings):.03f}s")
|
||||
```
|
||||
|
||||
prints:
|
||||
This prints:
|
||||
|
||||
```
|
||||
without dataflow parallelize -> 0.609s
|
||||
with dataflow parallelize -> 0.414s
|
||||
```
|
||||
|
||||
and the reason for that is:
|
||||
The reason for that is:
|
||||
|
||||
```
|
||||
// this is the generated MLIR for the circuit
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
## Improve parallelism
|
||||
|
||||
This guide teaches the different options for parallelism in Concrete and how to utilize them to improve the execution time of Concrete circuits.
|
||||
This guide introduces the different options for parallelism in **Concrete** and how to utilize them to improve the execution time of **Concrete** circuits.
|
||||
|
||||
Modern CPUs have multiple cores to perform computation and utilizing multiple cores is a great way to boost performance.
|
||||
|
||||
<!-- markdown-link-check-disable -->
|
||||
There are two kinds of parallelism in Concrete:
|
||||
There are two kinds of parallelism in **Concrete**:
|
||||
- Loop parallelism to make tensor operations parallel, achieved by using [OpenMP](https://www.openmp.org/)
|
||||
- Dataflow parallelism to make independent operations parallel, achieved by using [HPX](https://hpx.stellar-group.org/)
|
||||
<!-- markdown-link-check-enable -->
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
### Tensorizing operations
|
||||
|
||||
This guide teaches what tensorization is and how it can improve the execution time of Concrete circuits.
|
||||
This guide explains tensorization and how it can improve the execution time of **Concrete** circuits.
|
||||
|
||||
Tensors should be used instead of scalars when possible to maximize loop parallelism.
|
||||
|
||||
@@ -43,7 +43,7 @@ for tensorize in [False, True]:
|
||||
print(f" with tensorization -> {np.mean(timings):.03f}s")
|
||||
```
|
||||
|
||||
prints:
|
||||
This prints:
|
||||
|
||||
```
|
||||
without tensorization -> 0.214s
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
This guide explains how to optimize cryptographic parameters by specifying composition when using [modules](../../compilation/composing_functions_with_modules.md).
|
||||
|
||||
When using [modules](../../compilation/composing_functions_with_modules.md) make sure to specify [composition](../../compilation/composing_functions_with_modules.md#optimizing-runtimes-with-composition-policies) so that the compiler can select more optimal parameters based on how the functions in the module would be used.
|
||||
When using [modules](../../compilation/composing_functions_with_modules.md), make sure to specify [composition](../../compilation/composing_functions_with_modules.md#optimizing-runtimes-with-composition-policies) so that the compiler can select more optimal parameters based on how the functions in the module would be used.
|
||||
|
||||
For example:
|
||||
|
||||
@@ -55,11 +55,11 @@ with_composition = PowerWithComposition.compile(
|
||||
print(f" with composition -> {int(with_composition.complexity):>10_} complexity")
|
||||
```
|
||||
|
||||
prints:
|
||||
This prints:
|
||||
|
||||
```
|
||||
without composition -> 185_863_835 complexity
|
||||
with composition -> 135_871_612 complexity
|
||||
```
|
||||
|
||||
which means specifying composition resulted in ~35% improvement to complexity for computing `cube(square(x))`.
|
||||
It means that specifying composition resulted in ~35% improvement to complexity for computing `cube(square(x))`.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
### Adjusting table lookup error probability
|
||||
|
||||
This guide teaches how setting `p_error` configuration option can affect the performance of Concrete circuits.
|
||||
This guide explains how setting `p_error` configuration option can affect the performance of **Concrete** circuits.
|
||||
|
||||
Adjusting table lookup error probability is discussed extensively in [Table lookup exactness](../../core-features/table_lookups_advanced.md#table-lookup-exactness) section. The idea is to sacrifice exactness to gain performance.
|
||||
|
||||
@@ -20,7 +20,7 @@ for p_error in [(1 / 1_000_000), (1 / 100_000), (1 / 10_000), (1 / 1_000), (1 /
|
||||
print(f"p_error of {p_error:.6f} -> {int(circuit.complexity):_} complexity")
|
||||
```
|
||||
|
||||
prints:
|
||||
This prints:
|
||||
|
||||
```
|
||||
p_error of 0.000001 -> 294_773_524 complexity
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
## Optimize cryptographic parameters
|
||||
|
||||
This guide teaches how to help Concrete Optimizer to select more performant parameters to improve the execution time of Concrete circuits.
|
||||
This guide explains how to help **Concrete** Optimizer to select more performant parameters to improve the execution time of Concrete circuits.
|
||||
|
||||
The idea is to obtain more optimal cryptographic parameters (especially for table lookups) without changing the operations within the circuit.
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Optimization
|
||||
|
||||
This guide teaches how to optimize Concrete circuits extensively.
|
||||
This guide explains how to optimize Concrete circuits extensively.
|
||||
|
||||
It's split in 3 sections:
|
||||
- [Improve parallelism](./improve-parallelism/self.md): to show how to make circuits utilize more cores.
|
||||
- [Optimize table lookups](./optimize-table-lookups/self.md): to show how to optimize the most expensive operation in Concrete.
|
||||
- [Optimize cryptographic parameters](./optimize-cryptographic-parameters/self.md): to show how to make Concrete select more performant parameters.
|
||||
- [Improve parallelism](./improve-parallelism/self.md): to make circuits utilize more cores.
|
||||
- [Optimize table lookups](./optimize-table-lookups/self.md): to optimize the most expensive operation in Concrete.
|
||||
- [Optimize cryptographic parameters](./optimize-cryptographic-parameters/self.md): to make Concrete select more performant parameters.
|
||||
|
||||
Reference in New Issue
Block a user