Opened 3 years ago

Last modified 5 weeks ago

#7647 new feature request

UNPACK polymorphic fields

Reported by: liyang Owned by:
Priority: normal Milestone: 7.12.1
Component: Compiler Version: 7.6.1
Keywords: Cc: hackage.haskell.org@…, mnislaih@…, bgamari@…, tkn.akio@…, f@…, MikeIzbicki
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case:
Blocked By: Blocking:
Related Tickets: #3990 #9655 Differential Revisions:

Description

comment:9:ticket:3990 mentions the possibility of unpacking polymorphic fields. To quote:

[…]

What I mean by "polymorphic unpack" is this:

  data Poly a = MkP Bool {-# UNPACK #-} a 
  data Mango = MkMango {-# UNPACK #-} (Poly Int)

Now a value of type Poly t would be represented using two pointer fields, as usual (ie the UNPACK would have no direct effect on Poly). But a Mango value would be represented thus:

  data Mango = MkMangoRep Bool Int#

  MkMango :: Poly Int -> MangoRep
  MkMango (MkP b (I# i)) = MkMangoRep b i

  -- Pattern match      (MkMango p -> rhs)
  -- is transformed to  (MkMangoRep b i -> let p = MkP b (I# i) in rhs

Something like that would be rather nice. This ticket is just a reminder.

Thanks,
/Liyang

Change History (11)

comment:1 Changed 3 years ago by liyang

  • Cc hackage.haskell.org@… added

comment:2 Changed 2 years ago by igloo

  • difficulty set to Unknown
  • Milestone set to 7.8.1

comment:3 Changed 2 years ago by mnislaih

  • Cc mnislaih@… added

comment:4 Changed 23 months ago by bgamari

  • Cc bgamari@… added
  • Milestone changed from 7.8.1 to 7.10.1

Indeed this wouldn't be nice but clearly won't happen for 7.8.1. Punting to 7.10.

comment:5 Changed 9 months ago by akio

  • Cc tkn.akio@… added

comment:6 Changed 9 months ago by bitonic

  • Cc f@… added

comment:7 Changed 9 months ago by bgamari

This morning I was thinking about how this might work. Would unpacking be restricted only to single-constructor polymorphic types? For instance, if I had,

data Poly a = MkP !Bool {-# UNPACK #-} !a | MkP2

data Mango = MkMango {-# UNPACK #-} !(Poly Int)

Would I want to produce a representation that is the product of all of the unpacked variants? e.g..

data MangoRep = MangoRep1 !Bool !a | MangoRep2

Or would we want to simply not unpack multi-constructor types? This seems to be how monomorphic types are currently handled, if I understand the code correctly.

Moreover, how would a pattern match against an unpacked polymorphic type be lowered? Would we want to re-box Poly when pattern matching on Mango? Alternatively, we could somehow specialize functions on Poly to take the unboxed representation.

Thoughts?

comment:8 Changed 9 months ago by simonpj

  • Owner simonpj deleted

comment:9 Changed 8 months ago by thoughtpolice

  • Milestone changed from 7.10.1 to 7.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:10 Changed 5 weeks ago by thomie

  • Cc MikeIzbicki added

See this blog post for a request for "polymorphic unpacking", in the section "Lesson 1: Polymorphic code in GHC is slower than it needs to be."

The blog post also refers to a reddit discussion on the subject.

comment:11 Changed 5 weeks ago by thomie

Note: See TracTickets for help on using tickets.