You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RUN wget http://download.savannah.gnu.org/releases/libunwind/libunwind-${LIBUNWIND_VERSION}.tar.gz --output-document ${DOWNLOADS}/libunwind-${LIBUNWIND_VERSION}.tar.gz
-**ZigZagDrgPoRep** (implemented as a specialized **LayeredDrgPoRep**)
15
+
-**StackedDrgPoRep**
16
16
-**PoSt** (Proof-of-Spacetime)
17
17
18
18
@@ -94,7 +94,7 @@ Note: On macOS you need `gtime` (`brew install gnu-time`), as the built in `time
94
94
95
95
## Profiling
96
96
97
-
For development purposes we have an (experimental) support for CPU and memory profiling in Rust through a [`gperftools`](https://github.com/dignifiedquire/rust-gperftools) binding library. These can be enabled though the `cpu-profile` and `heap-profile` features in `filecoin-proofs`. An example setup can be found in this [`Dockerfile`](./Dockerfile-profile) to profile CPU usage for the [`zigzag`](https://github.com/filecoin-project/rust-fil-proofs/blob/e6fa4232404641bb4be1ffc42944d2e734ab9748/filecoin-proofs/examples/zigzag.rs#L40-L61) example.
97
+
For development purposes we have an (experimental) support for CPU and memory profiling in Rust through a [`gperftools`](https://github.com/dignifiedquire/rust-gperftools) binding library. These can be enabled though the `cpu-profile` and `heap-profile` features in `filecoin-proofs`. An example setup can be found in this [`Dockerfile`](./Dockerfile-profile) to profile CPU usage for the [`stacked`](https://github.com/filecoin-project/rust-fil-proofs/blob/master/filecoin-proofs/examples/stacked.rs#L40-L61) example.
98
98
99
99
## Logging
100
100
@@ -151,7 +151,7 @@ While replicating and generating the Merkle Trees (MT) for the proof at the same
151
151
152
152
### Speed
153
153
154
-
One of the most computational expensive operations during replication (besides the encoding itself) is the generation of the indexes of the (expansion) parents in the ZigZag graph, implemented through a Feistel cipher (used as a pseudorandom permutation). To reduce that time we provide a caching mechanism to generate them only once and reuse them throughout replication (across the different layers). Already built into the system it can be activated with the environmental variable
154
+
One of the most computational expensive operations during replication (besides the encoding itself) is the generation of the indexes of the (expansion) parents in the Stacked graph, implemented through a Feistel cipher (used as a pseudorandom permutation). To reduce that time we provide a caching mechanism to generate them only once and reuse them throughout replication (across the different layers). Already built into the system it can be activated with the environmental variable
155
155
156
156
```
157
157
FIL_PROOFS_MAXIMIZE_CACHING=1
@@ -161,15 +161,15 @@ To check that it's working you can inspect the replication log to find `using pa
161
161
162
162
(You can also verify if the cache is working by inspecting the time each layer takes to encode, `encoding, layer:` in the log, where the first two layers, forward and reverse, will take more time than the rest to populate the cache while the remaining 8 should see a considerable time drop.)
163
163
164
-
In the most extreme case, to reduce time at the cost of *a lot* of memory consumption you can turn on the feature that stores MTs on memory (`mem-trees`) instead of on disk (the default) to generate them all on RAM and avoid disk I/O (if the HW doesn't have enough RAM to handle the MTs, roughly 20x the sector size, this won't have the desired effect as the OS will start backing them on disk anyway). For example, to run the `zigzag` example with this feature turned on you'd need to indicate so to `cargo`,
164
+
In the most extreme case, to reduce time at the cost of *a lot* of memory consumption you can turn on the feature that stores MTs on memory (`mem-trees`) instead of on disk (the default) to generate them all on RAM and avoid disk I/O (if the HW doesn't have enough RAM to handle the MTs, roughly 20x the sector size, this won't have the desired effect as the OS will start backing them on disk anyway). For example, to run the `stacked` example with this feature turned on you'd need to indicate so to `cargo`,
165
165
166
166
```
167
167
# NEEDS TO BE RUN INSIDE `storage-proofs\` directory
168
168
# for the `--features` to take effect.
169
169
cargo run \
170
170
-p filecoin-proofs \
171
171
--release \
172
-
--example zigzag \
172
+
--example stacked \
173
173
--features \
174
174
mem-trees \
175
175
-- \
@@ -188,7 +188,7 @@ The following benchmarks were observed when running replication on 1MiB (1024 ki
188
188
189
189
```
190
190
$ cargo build --bin benchy --release
191
-
$ env time -v cargo run --bin benchy --release -- zigzag --size=1024
191
+
$ env time -v cargo run --bin benchy --release -- stacked --size=1024
0 commit comments