I haven't been following this discussion too closely, but in my research work I found that some of the benefits that I wanted in this direction were already there with pointer tagging.
On Thu, Oct 15, 2020 at 12:59 PM David Feuer <david.fe...@gmail.com> wrote: > Yes, that's something quite different. We'd need a whole different heap > object type for such MVars and TVars. My approach covers the case where the > unboxed thing can only take on a few values, for some value of "a few" > which, depending on implementation, may or may not be very small. If the > nulls point to actual heap objects in pre-allocated pinned memory (say), > then up to 64 or so might be reasonable. If they point to "invalid" address > space, then the numbers could go up a good bit. > > On Thu, Oct 15, 2020, 12:50 PM Carter Schonwald < > carter.schonw...@gmail.com> wrote: > >> 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 >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs