When does the UNPACK pragma work?
Hi, I'm trying to speed up Data.Time (the time package) 'cause my program is spending a very substantial fraction of time manipulating dates. I decided to start with strictifying and unpacking the date/time types, as there's no point in having them be lazy and I indeed had a lot of allocation in date/time arithmetic in my performance profile. data UTCTime = UTCTime { utctDay :: {-# UNPACK #-} !Day, utctDayTime :: {-# UNPACK #-} !DiffTime } (unpacks and strictness mine) newtype Day = ModifiedJulianDay {toModifiedJulianDay :: Integer} newtype DiffTime = MkDiffTime Pico And Pico is also essentially a newtype for Integer. So, I'm getting warnings on this definition of UTCTime. QUESTION: Is it the case that I can only UNPACK primitive fields, and not even their newtypes? Data\Time\Clock\UTC.hs:30:16: Warning: Ignoring unusable UNPACK pragma on the first argument of `UTCTime' In the definition of data constructor `UTCTime' In the data type declaration for `UTCTime' Data\Time\Clock\UTC.hs:30:16: Warning: Ignoring unusable UNPACK pragma on the second argument of `UTCTime' In the definition of data constructor `UTCTime' In the data type declaration for `UTCTime' -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/
On Friday 28 October 2011, 11:41:15, Eugene Kirpichov wrote:
newtype Day = ModifiedJulianDay {toModifiedJulianDay :: Integer} newtype DiffTime = MkDiffTime Pico
And Pico is also essentially a newtype for Integer.
So, I'm getting warnings on this definition of UTCTime. QUESTION: Is it the case that I can only UNPACK primitive fields, and not even their newtypes?
The problem is that you can't {-# UNPACK #-} Integer. You can only unpack single-constructor types.
Oh, I see, thanks! So then, I guess, the solution would be to use a fixed-precision integer type instead. On Fri, Oct 28, 2011 at 1:54 PM, Daniel Fischer < daniel.is.fischer@googlemail.com> wrote:
On Friday 28 October 2011, 11:41:15, Eugene Kirpichov wrote:
newtype Day = ModifiedJulianDay {toModifiedJulianDay :: Integer} newtype DiffTime = MkDiffTime Pico
And Pico is also essentially a newtype for Integer.
So, I'm getting warnings on this definition of UTCTime. QUESTION: Is it the case that I can only UNPACK primitive fields, and not even their newtypes?
The problem is that you can't {-# UNPACK #-} Integer. You can only unpack single-constructor types.
-- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/
Another question: Can I unpack some fields in a record and not unpack
others? Does their order matter then?
On Fri, Oct 28, 2011 at 1:57 PM, Eugene Kirpichov
Oh, I see, thanks!
So then, I guess, the solution would be to use a fixed-precision integer type instead.
On Fri, Oct 28, 2011 at 1:54 PM, Daniel Fischer < daniel.is.fischer@googlemail.com> wrote:
On Friday 28 October 2011, 11:41:15, Eugene Kirpichov wrote:
newtype Day = ModifiedJulianDay {toModifiedJulianDay :: Integer} newtype DiffTime = MkDiffTime Pico
And Pico is also essentially a newtype for Integer.
So, I'm getting warnings on this definition of UTCTime. QUESTION: Is it the case that I can only UNPACK primitive fields, and not even their newtypes?
The problem is that you can't {-# UNPACK #-} Integer. You can only unpack single-constructor types.
-- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/
-- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/
On Friday 28 October 2011, 11:57:54, Eugene Kirpichov wrote:
Another question: Can I unpack some fields in a record and not unpack others?
Yes, no problem with that.
Does their order matter then?
In what way? The order of the fields in the definition of the type will determine the order in which the components (pointers/unpacked values) appear in the constructor. That may influence performance, but I wouldn't expect a significant difference.
On Fri, Oct 28, 2011 at 2:32 PM, Daniel Fischer < daniel.is.fischer@googlemail.com> wrote:
On Friday 28 October 2011, 11:57:54, Eugene Kirpichov wrote:
Another question: Can I unpack some fields in a record and not unpack others?
Yes, no problem with that.
Does their order matter then?
In what way? The order of the fields in the definition of the type will determine the order in which the components (pointers/unpacked values) appear in the constructor. That may influence performance, but I wouldn't expect a significant difference.
Oh, OK. I was just thinking, maybe, you can only unpack a prefix of the field set... -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/
newtypes always turn into no code. The UNPACK is therefore asking to unpack the Integer inside a Day, and that we can't do because Integer has more than one data constructor. Ditto Pico. So just drop the UNPACKS. Keep the ! though, to keep it strict S From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Eugene Kirpichov Sent: 28 October 2011 10:41 To: Haskell Cafe Subject: [Haskell-cafe] When does the UNPACK pragma work? Hi, I'm trying to speed up Data.Time (the time package) 'cause my program is spending a very substantial fraction of time manipulating dates. I decided to start with strictifying and unpacking the date/time types, as there's no point in having them be lazy and I indeed had a lot of allocation in date/time arithmetic in my performance profile. data UTCTime = UTCTime { utctDay :: {-# UNPACK #-} !Day, utctDayTime :: {-# UNPACK #-} !DiffTime } (unpacks and strictness mine) newtype Day = ModifiedJulianDay {toModifiedJulianDay :: Integer} newtype DiffTime = MkDiffTime Pico And Pico is also essentially a newtype for Integer. So, I'm getting warnings on this definition of UTCTime. QUESTION: Is it the case that I can only UNPACK primitive fields, and not even their newtypes? Data\Time\Clock\UTC.hs:30:16: Warning: Ignoring unusable UNPACK pragma on the first argument of `UTCTime' In the definition of data constructor `UTCTime' In the data type declaration for `UTCTime' Data\Time\Clock\UTC.hs:30:16: Warning: Ignoring unusable UNPACK pragma on the second argument of `UTCTime' In the definition of data constructor `UTCTime' In the data type declaration for `UTCTime' -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/
participants (3)
-
Daniel Fischer -
Eugene Kirpichov -
Simon Peyton-Jones