Performance of small allocations via prim ops

[Ben Gamari]

Harendra Kumar <harendra.kumar at gmail.com> writes:

> I am confused by this flag. This flag allows us to allocate statically
> known arrays sizes of <= n to be allocated from the current nursery block.
> But looking at the code in allocateMightFail, as I interpret it, any size
> array up to LARGE_OBJECT_THRESHOLD is anyway allocated from the current
> nursery block. So why have this option? Why not fix this to
> LARGE_OBJECT_THRESHOLD? Maybe I am missing something.
>
In principle we could do so. The motivation for making this a flag isn't
immediately clear from the commit implementing this optimisation
(1eece45692fb5d1a5f4ec60c1537f8068237e9c1).

One complication is that currently GHC has no way to know the value of
LARGE_OBJECT_THRESHOLD (which is a runtime system macro). Typically to
handle this sort of thing we use utils/deriveConstants to generate a
Haskell binding mirroring the value of the C declaration. However,
as GHC becomes runtime-retargetable we may need to revisit this design.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230409/5fe1d8e4/attachment.sig>