ed 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
>>>>>>>>
olume / mutation
>>>>>>>> volume (to ensure generational hypothesis stays valid), and providing
>>>>>>>> tools
>>>>>>>> to incrementally reduce the pressure with local changes would be good.
>>>>>>>>
>>>
;>>> machinery
>>>>>>> that supports unboxed values.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Oct 15, 2020 at 5:32 AM Andreas Klebinger <
>>>>>>> klebinger.andr...@
020 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 practi
ons 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
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 expo
head, 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
osts 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 nestin
re 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
rom: Andrew Martin
> Date: Wed, Oct 14, 2020, 4:14 PM
> Subject: Re: Restricted sums in BoxedRep
> To: David Feuer
>
>
> 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 s
-
From: *Andrew Martin* mailto:andrew.thadd...@gmail.com>>
Date: Wed, Oct 14, 2020, 4:14 PM
Subject: Re: Restricted sums in BoxedRep
To: David Feuer mailto:david.fe...@gmail.com>>
You'll have to forward this to the ghc-devs list to share it with
others since I'm not curr
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
Date: Wed, Oct 14, 2020, 4:14 PM
Subject: Re: Restricted sums in
Yes, I think you're getting the gist. Pattern matching with one or two
nulls is just an equality test or three. In practice, we'd want a fixed
number of evenly spaced nulls, allowing jump table techniques to be used
when there are more cases. We'd presumably have a hard limit for the number
of null
Ok, I believe get it now,
Let's imagine (to take only the simplest case) that we have a `Nullable# a`
type, such that `Nullable# a = (# (##) | a #)`. What would be the kind of
`Nullable#`? I imagine that it would be something like `TYPE (BoxedRep
Lifted) -> TYPE (BoxedRep Nullable)`.
Then you wou
I don't know your terminology, sorry. By "null" I'm referring to something
distinguished, of which there can be more than one. These can be pointers
to statically allocated objects if necessary, though pointers in an unused
address range would probably be nicer. My goal is to be able to shove a
com
I don't imagine it would be hard for the GC to check that a pointer is null
before following it. The argument may be, though, that it's too high a
price to pay for the occasional use of a null pointer. (I must add that I
have no opinion, or idea really, on this)
On Wed, Oct 14, 2020 at 1:54 PM Seb
I believe Simon told me once that NULL pointers in places we assume
BoxedRep things are not an option, because the GC assumes it is free to
follow that pointer. It won't check if it's NULL or not.
That's also the reason why we lower `LitRubbish` (which we use for absent
BoxedRep literals) as `()` w
I may have misunderstood, but my understanding is the following:
- Since a is a boxed type, it can never be the null pointer
- So I can use a null pointer unambiguously
Let's call this null-pointer expanded type, `Nullable# a`, it is now a
different sort than `a`, since it can have the null point
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 lifte
19 matches
Mail list logo
