Opened 12 years ago

Closed 8 years ago

#2338 closed feature request (fixed)

unpack primitive types by default in data? and NOUNPACK?

Reported by: Isaac Dupree Owned by: simonmar
Priority: high Milestone: 7.4.1
Component: Compiler Version: 6.8.2
Keywords: Cc: leuschner@…, johan.tibell@…, mail@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

We should have a NOUNPACK pragma paralleling UNPACK so that we can unpack data types by default without completely taking away control from the programmer. (Currently, NOUNPACK would only have any effect when -funbox-strict-fields is given.)

We may want to unpack strict primitive types by default (at least with -O), such as in the following

data D a = D !Int !Double

(Because those are the types that it's most often useful to pass around in registers, for one thing?)

But it's probably worth testing on a lot of existing code to make sure it's never too much of a penalty in practice. (But considering the amount that people just use -funbox-strict-fields without thinking, because having to place all those UNPACK pragmas is annoying, making the default be a little smarter is probably useful.)

see parts of this thread: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/40294/focus=40316

related tickets, in order of decreasing relatedness: #605, #1349; #1433, #2289

Attachments (1)

0001-added-NOUNPACK-pragma-see-2338.patch (7.0 KB) - added by StefanWehr 8 years ago.

Download all attachments as: .zip

Change History (19)

comment:1 Changed 12 years ago by igloo

difficulty: Unknown
Milestone: 6.10.1

Makes sense to me.

comment:2 Changed 11 years ago by igloo

Milestone: 6.10.16.12 branch

comment:3 Changed 11 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:4 Changed 11 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:5 Changed 10 years ago by igloo

Milestone: 6.12 branch6.12.3

comment:6 Changed 10 years ago by igloo

Milestone: 6.12.36.14.1
Priority: normallow

comment:7 Changed 9 years ago by igloo

Milestone: 7.0.17.0.2

comment:8 Changed 9 years ago by igloo

Milestone: 7.0.27.2.1

comment:9 Changed 8 years ago by igloo

Milestone: 7.2.17.4.1

comment:10 Changed 8 years ago by dleuschner

Cc: leuschner@… added
Type of failure: None/Unknown

I'd love this feature. Currently we've got 559 data type definitions with more that 2800 fields in our project. Most fields are strict fields. We're using -funbox-strict-fields because that's what we want for ~95% of our strict fields. Sometimes we want boxed strict fields so we leave out the strictness annotation in the data type but we then have to change all "construction sites" to make sure that the field is strict. If we had {-# NOUNPACK #-} we could leave the strictness annotation in place and still get a boxed field. The other option, to explicitly unbox all of our >2800 data constructor fields is not very appealing.

comment:11 Changed 8 years ago by tibbe

Cc: johan.tibell@… added

A first step could be to just switch the default and run some benchmarks (e.g. nofib) and see what the results are. Semantically it should be fine to unbox strict fields.

comment:12 Changed 8 years ago by simonpj

Fair enough. I don't think this'd be hard to implement if anyone wants to make a patch. Nothing fundamentally different going on, just different UI.

Simon

comment:13 Changed 8 years ago by simonmar

One open question I see is what is considered to be a "primitive type"?

My first guess would be "a type which would UNPACK to a single field of unboxed type". That would encompass basic types like Int, newtypes of those, and multiple layers of UNPACKing too (e.g. a field of type T would be automatically unpacked if data T = T !Int). But do you want to include types that unpack to more than one unboxed field? How many?

I'd be sceptical about relying on nofib as a good benchmark here, I don't think the programs in there tend to define many datatypes. Look at fibon too, probably.

Changed 8 years ago by StefanWehr

comment:14 Changed 8 years ago by StefanWehr

Cc: mail@… added
Status: newpatch

I've attached a patch that adds support for the NOUNPACK pragma. The patch does not address the issue of unpacking primitive types by default. Please tell me if anything is wrong with the patch, it's my first GHC patch ;-)

comment:15 Changed 8 years ago by dleuschner

Thanks Stefan! :-))

Johan, we're using -funbox-strict-fields and our benchmarks tell uns, that in our case it's best to unpack nearly all of the strict fields. That's why we do that by default. It's just a few cases were unboxing is bad but there it increases allocations and makes up for about 5% of total mutator time. (That's why NOUNPACK would be so helpful because we then can use strict fields with -funbox-strict-fields and explicitly define where we want to keep the strict fields boxed.)

comment:16 Changed 8 years ago by simonmar

Owner: set to simonmar
Priority: lowhigh

Patch looks fine, I'll validate and push.

comment:17 Changed 8 years ago by wehr@…

commit aa564232ee67d46403a69b02b0b8faf2455894f8

Author: Stefan Wehr <wehr@factisresearch.com>
Date:   Wed Nov 9 09:37:17 2011 +0100

    added NOUNPACK pragma (see #2338)

 compiler/basicTypes/BasicTypes.lhs  |    2 ++
 compiler/basicTypes/DataCon.lhs     |    1 +
 compiler/iface/BinIface.hs          |    4 +++-
 compiler/parser/Lexer.x             |    2 ++
 compiler/parser/Parser.y.pp         |    2 ++
 compiler/typecheck/TcTyClsDecls.lhs |    1 +
 docs/users_guide/glasgow_exts.xml   |   20 ++++++++++++++++++++
 docs/users_guide/using.xml          |    7 ++++++-
 8 files changed, 37 insertions(+), 2 deletions(-)

comment:18 Changed 8 years ago by simonmar

Resolution: fixed
Status: patchclosed
Note: See TracTickets for help on using tickets.