[GHC] #15414: Why both gen and gen_no in bdescr?

[GHC]

#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