Opened 5 years ago

Last modified 6 weeks ago

#7647 new feature request

UNPACK polymorphic fields

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

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 (17)

comment:1 Changed 5 years ago by liyang

Cc: hackage.haskell.org@… added

comment:2 Changed 4 years ago by igloo

difficulty: Unknown
Milestone: 7.8.1

comment:3 Changed 4 years ago by mnislaih

Cc: mnislaih@… added

comment:4 Changed 4 years ago by bgamari

Cc: bgamari@… added
Milestone: 7.8.17.10.1

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

comment:5 Changed 3 years ago by akio

Cc: tkn.akio@… added

comment:6 Changed 3 years ago by bitonic

Cc: f@… added

comment:7 Changed 3 years 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 3 years ago by simonpj

Owner: simonpj deleted

comment:9 Changed 3 years ago by thoughtpolice

Milestone: 7.10.17.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 2 years 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 2 years ago by thomie

comment:12 Changed 2 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:13 Changed 2 years ago by vagarenko

Cc: vagarenko added

comment:14 Changed 20 months ago by thomie

Milestone: 8.0.1

comment:15 Changed 9 months ago by osa1

Cc: osa1 added

comment:16 Changed 8 weeks ago by danilo2

Cc: danilo2 added

comment:17 Changed 6 weeks ago by ethercrow

Cc: ethercrow added
Note: See TracTickets for help on using tickets.