@@ -465,7 +465,7 @@ A total of 387 words which is 3, 096 bytes or roughly 3KiB, just for 32
465465elements! Unfortunately, this also will not be a cache friendly data structure.
466466To store 387 words we need :math: `\frac {387 }{8 } = 48 ` cache lines. But 387 is
467467not a multiple of 2, so there will be :math: `387 \bmod {} 8 = 3 ` words of
468- leftover space on the final cache line [# ]_. A more cache friendly data
468+ leftover space on the final cache line [#f1 ]_. A more cache friendly data
469469structure would ensure that a ``Full `` always fit evenly into a set of cache
470470lines and would thereby avoid fragmenting the cache. One caveat is that this
471471wasted space will change depending on the sizes of the key and value.
@@ -731,11 +731,11 @@ Which is just what we expected: one word (``.quad (,)_con_info``) for the data
731731constructor header, one for ``fst `` (``.quad stg_INTLIKE_closure+273 `` ), and
732732one ``snd `` (``.quad stg_INTLIKE_closure+289 ``). However, GHC has added another
733733word that is mysteriously set to 3: ``.quad 3 ``. This extra word is an
734- optimization that GHC applies which tags the symbol ``Main.a_pair_closure `` as a
734+ optimization that GHC applies which tags [ #f3 ]_ the symbol ``Main.a_pair_closure `` as a
735735static constructor that contains no :term: `CAF ` references. This tag (the 3)
736736instructs the garbage collector to ignore this symbol during garbage collection.
737737If ``Main.a_pair_closure `` was found to possibly have a CAF then the tag would
738- have been 0 but the extra word would still exist [# ]_ . So does this mean that
738+ have been 0 but the extra word would still exist [#f2 ]_ . So does this mean that
739739our analysis is incorrect? No, this data is only checked and loaded during a
740740garbage collection event, it is a by product of our abuse of ``NOINLINE `` to
741741create a static top-level closure.
@@ -1067,18 +1067,18 @@ that data you'll be all but guaranteed to speed up your system.
10671067References
10681068==========
10691069
1070- .. [# ] The HashMap behaves this way because of `yours truly
1071- <https://github.com/haskell-unordered-containers/unordered-containers/pull/317> `__.
1072- Even though the cache behavior is poor, the 16-bit base was worse because
1073- it created HashMaps with a more deeply nested structure. This meant even
1074- *more * pointer chasing in full cases. For the interested, you can observe
1075- the effect in the data posted in the pull request I have linked.
1070+ .. [#f1 ] The HashMap behaves this way because of `yours truly
1071+ <https://github.com/haskell-unordered-containers/unordered-containers/pull/317> `__.
1072+ Even though the cache behavior is poor, the 16-bit base was worse because
1073+ it created HashMaps with a more deeply nested structure. This meant even
1074+ *more * pointer chasing in full cases. For the interested, you can observe
1075+ the effect in the data posted in the pull request I have linked.
10761076
1077- .. [# ] The `Haskell Wiki
1078- <https://www.fpcomplete.com/blog/2016/05/weigh-package/> `_ page. Although
1079- it has not been updated in some time.
1077+ .. [#f2 ] The `Haskell Wiki
1078+ <https://www.fpcomplete.com/blog/2016/05/weigh-package/> `_ page. Although
1079+ it has not been updated in some time.
10801080
1081- .. [# ] For the interested, `here
1081+ .. [#f3 ] For the interested, `here
10821082 <https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/StgToCmm/Heap.hs?ref_type=heads#L215> `__
10831083 is where the tag is applied and `here
10841084 <https://gitlab.haskell.org/ghc/ghc/-/blob/master/rts/sm/Storage.h?ref_type=heads#L134> `__
0 commit comments