Indeed, I mean things that aren’t pointery, and could be represented by a tvar paired with a mutable byte array or mvar with mutable byte array, but which we’d want considered as a single heap object from the rts/gc perspective.
On Thu, Oct 15, 2020 at 11:58 AM David Feuer <david.fe...@gmail.com> wrote: > Sorry, unlifted, not unboxed... > > On Thu, Oct 15, 2020, 11:57 AM David Feuer <david.fe...@gmail.com> wrote: > >> Putting unboxed things in TVar, MVar, etc., is part of Andrew Martin's >> accepted BoxedRep proposal. >> >> On Thu, Oct 15, 2020, 11:44 AM Carter Schonwald < >> carter.schonw...@gmail.com> wrote: >> >>> A related idea that came up recently and is perhaps simpler ties into >>> this via the lens of having unboxed Mvars/tvars (even if it’s restricted to >>> just things we can embed in a word64#) >>> >>> This came up in >>> https://gitlab.haskell.org/ghc/ghc/-/issues/18798#note_307410, where >>> viktor had millions of independent mvars holding what’s essentially a >>> strict unit ()! >>> >>> The motivation in this later scenario is that in high concurrency >>> settings, the less trivial stuff the gc needs to trace under updates, the >>> better ghc scales. >>> >>> This may not be a use case david has in mind, but certainly seems >>> related. >>> >>> Phrased more succinctly: gc perf dominates large heap / many core >>> computation in Haskell via sensitivity to allocation volume / mutation >>> volume (to ensure generational hypothesis stays valid), and providing tools >>> to incrementally reduce the pressure with local changes would be good. >>> >>> So I’d propose / suggest that a baby step towards what david asks would >>> be for us to work out some manner of unboxed tvar/mvar ref machinery that >>> supports unboxed values. >>> >>> >>> >>> On Thu, Oct 15, 2020 at 5:32 AM Andreas Klebinger < >>> klebinger.andr...@gmx.at> wrote: >>> >>>> From a implementors perspective my main questions would be: >>>> >>>> * How big is the benefit in practice? How many use cases are there? >>>> * How bad are the costs? (Runtime overhead, rts complexity, ...) >>>> >>>> The details of how this would be exposed to a user would are important. >>>> But if the costs are too high for the drawbacks then it becomes a moot >>>> point. >>>> >>>> >>>> David Feuer schrieb am 14.10.2020 um 22:21: >>>> >>>> Forwarded from Andrew Martin below. I think we want more than just >>>> Maybe (more than one null), but the nesting I described is certainly more >>>> convenience than necessity. >>>> >>>> ---------- Forwarded message --------- >>>> From: Andrew Martin <andrew.thadd...@gmail.com> >>>> Date: Wed, Oct 14, 2020, 4:14 PM >>>> Subject: Re: Restricted sums in BoxedRep >>>> To: David Feuer <david.fe...@gmail.com> >>>> >>>> >>>> You'll have to forward this to the ghc-devs list to share it with >>>> others since I'm not currently subscribed to it, but I've had this same >>>> thought before. It is discussed at >>>> https://github.com/andrewthad/impure-containers/issues/12. Here's the >>>> relevant excerpt: >>>> >>>>> Relatedly, I was thinking the other day that after finishing >>>>> implementing >>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0203-pointer-rep.rst, >>>>> I should really look at seeing if it's possible to add this >>>>> maybe-of-a-lifted value trick straight to GHC. I think that with: >>>>> >>>>> data RuntimpRep >>>>> = BoxedRep Levity >>>>> | MaybeBoxedRep Levity >>>>> | IntRep >>>>> | ... >>>>> >>>>> data BuiltinMaybe :: forall (v :: Levity). TYPE v -> TYPE ('MaybeBoxedRep >>>>> v) >>>>> >>>>> This doesn't have the nesting issues because the kind system prevents >>>>> nesting. But anyway, back to the original question. I would recommend not >>>>> using Maybe.Unsafe and using unpacked-maybe instead. The latter is >>>>> definitely safe, and it only costs an extra machine word of space in each >>>>> data constructor it gets used in, and it doesn't introduce more >>>>> indirections. >>>>> >>>> >>>> On Tue, Oct 13, 2020 at 5:47 PM David Feuer <david.fe...@gmail.com> >>>> wrote: >>>> >>>>> Null pointers are widely known to be a lousy language feature in >>>>> general, but there are certain situations where they're *really* useful >>>>> for >>>>> compact representation. For example, we define >>>>> >>>>> newtype TMVar a = TMVar (TVar (Maybe a)) >>>>> >>>>> We don't, however, actually use the fact that (Maybe a) is lifted. So >>>>> we could represent this much more efficiently using something like >>>>> >>>>> newtype TMVar a = TMVar (TVar a) >>>>> >>>>> where Nothing is represented by a distinguished "null" pointer. >>>>> >>>>> While it's possible to implement this sort of thing in user code (with >>>>> lots of fuss and care), it's not very nice at all. What I'd really like to >>>>> be able to do is represent certain kinds of sums like this natively. >>>>> >>>>> Now that we're getting BoxedRep, I think we can probably make it >>>>> happen. The trick is to add a special Levity constructor representing sums >>>>> of particular shapes. Specifically, we can represent a type like this if >>>>> it >>>>> is a possibly-nested sum which, when flattened into a single sum, consists >>>>> of some number of nullary tuples and at most one Lifted or Unlifted type. >>>>> Then we can have (inline) primops to convert between the BoxedRep and the >>>>> sum-of-sums representations. >>>>> >>>>> Anyone have thoughts on details for what the Levity constructor >>>>> arguments might look like? >>>>> >>>> >>>> >>>> -- >>>> -Andrew Thaddeus Martin >>>> >>>> >>>> _______________________________________________ >>>> ghc-devs mailing >>>> listghc-devs@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs@haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>>
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs