#15414: Why both gen and gen_no in bdescr? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description:
Block descriptors currently contain both `gen` (a `generation *`) and `gen_no` (a `uint16_t, which is `gen->no` cached). I wonder whether it would be worthwhile to drop the former and always use `generations[bd->gen_no]`. Afterall, this would save an entire word per descriptor which may improve our caches' coverage of the bdescr region appreciably. Presumably the `generations` array would be hot enough to stay in cache in such a scheme, so I would guess that the cost would be small-ish.
Simon, have you measured this in the past?
New description: Block descriptors currently contain both `gen` (a `generation *`) and `gen_no` (a `uint16_t`, which is `gen->no` cached). I wonder whether it would be worthwhile to drop the former and always use `generations[bd->gen_no]`. Afterall, this would save an entire word per descriptor which may improve our caches' coverage of the bdescr region appreciably. Presumably the `generations` array would be hot enough to stay in cache in such a scheme, so I would guess that the cost would be small-ish. Simon, have you measured this in the past? -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15414#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler