diff options
| author | Sebastiano Tronto <sebastiano@tronto.net> | 2025-12-28 23:24:59 +0100 |
|---|---|---|
| committer | Sebastiano Tronto <sebastiano@tronto.net> | 2025-12-28 23:24:59 +0100 |
| commit | 6c000c39dde57233df233c8e448dd189958ae013 (patch) | |
| tree | cdc91ce52a83059b7f83ca1c714642f42c9b3aee /doc | |
| parent | 83270dcaeae598323b9cb2ae5a1a892ac5f72091 (diff) | |
| download | nissy-core-6c000c39dde57233df233c8e448dd189958ae013.tar.gz nissy-core-6c000c39dde57233df233c8e448dd189958ae013.zip | |
Update doc
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/h48.md | 14 |
1 files changed, 14 insertions, 0 deletions
| @@ -315,6 +315,20 @@ inverse position*, then the coordinate on the normal position has not | |||
| 315 | changed. Thus if we keep track of the last computed pruning value, | 315 | changed. Thus if we keep track of the last computed pruning value, |
| 316 | we can reuse it and avoid an expensive table lookup. | 316 | we can reuse it and avoid an expensive table lookup. |
| 317 | 317 | ||
| 318 | ### Pruning pipeline and prefetching | ||
| 319 | |||
| 320 | To improve the memory access pattern and exploit | ||
| 321 | [prefetching](https://en.wikipedia.org/wiki/Cache_prefetching) | ||
| 322 | opportunities, we don't expand each neighbor one by one in the | ||
| 323 | pruning phase. Instead, we employ a *pruning pipeline*, where we | ||
| 324 | first compute the cube and inverse position for each neighbor, and | ||
| 325 | then we proceed through a series of stages, at each of which we | ||
| 326 | compute some prune off some nodes and we pre-compute the data | ||
| 327 | necessary for the next step. | ||
| 328 | |||
| 329 | This pipeline-based strategy gives an speedup of around 25%. | ||
| 330 | Adding manual prefetching, we get an additional 20% speedup. | ||
| 331 | |||
| 318 | ### Other optimizations | 332 | ### Other optimizations |
| 319 | 333 | ||
| 320 | The H48 solver uses various other optimizations. | 334 | The H48 solver uses various other optimizations. |
