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
Remove extra data allocation used for MT generation (#837)
Make (a small) part of the replication the replication process sequential to avoid creating an extra `mmap` the size of a sector size. Decrease memory usage by 1x. Increase replication time (for parallel setups which will waste part of that parallelism) by a small fraction (encoding time still dominates).
Copy file name to clipboardExpand all lines: README.md
+1-9Lines changed: 1 addition & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -176,15 +176,7 @@ cargo build \
176
176
--size 1048576
177
177
```
178
178
179
-
To optimize even more for memory there's another option (used in addition to the `disk-trees` feature) to generate all MTs in sequential order, to make sure we can offload them to disk before we start buildding the next one,
180
-
181
-
```
182
-
FIL_PROOFS_GENERATE_MERKLE_TREES_IN_PARALLEL=0
183
-
```
184
-
185
-
You can inspect that it's working also in the replication log, where you'll see that the MTs are all generated in order without any layer index out of place.
186
-
187
-
All these optimizations (`disk-trees` with a directory to offload MTs plus sequential generation) should reduce the maximum RSS, in the `zigzag` example, to 3 times the sector size used (so in the above command that tested ZigZag with a 1 GiB sector the maximum RSS reported by commands like `/usr/bin/time -v` should not exceed 3 GiB, please submit an issue if you observe otherwise).
179
+
This optimization should reduce the maximum RSS, in the `zigzag` example, to 1-2 times the sector size used (so in the above command that tested ZigZag with a 1 GiB sector the maximum RSS reported by commands like `/usr/bin/time -v` should not exceed 2 GiB, please submit an issue if you observe otherwise).
/// Each element in the `path` vector consists of a tuple `(hash, is_right)`, with `hash` being the the hash of the node at the current level and `is_right` a boolean indicating if the path is taking the right path.
0 commit comments