[GHC] #6135: Unboxed Booleans

[GHC]

#6135: Unboxed Booleans
---------------------------------+------------------------------------------
    Reporter:  benl              |       Owner:                  
        Type:  feature request   |      Status:  new             
    Priority:  normal            |   Milestone:  7.8.1           
   Component:  Compiler          |     Version:  7.4.1           
    Keywords:                    |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown    
  Difficulty:  Unknown           |    Testcase:                  
   Blockedby:                    |    Blocking:                  
     Related:  #605              |  
---------------------------------+------------------------------------------

Comment(by simonpj):

 See [wiki:PrimBool].

 Janek, great initiative thanks.  But I think it would be helpful to
 articulate a very clear story about the ''goal''.  I believe that the goal
 is to achieve much better performance, without changing the source
 language.  The programmer does not change the program, but they run
 faster.

 If so, then can we have (on the wiki page, not here):

  * A description of ''why'' programs will go faster, with specific
 examples.

  * Some example programs that will in fact go faster. Maybe you can code
 the examples up in Haskell, using inconvenient and messy `Int#` or
 whatever, to demonstrate that they really do go faster.

 The sub-text is that I only want to introduce new complexity if it
 demonstrably buys us something.

 One reason that things may go faster is this.  At the moment, if a
 function is strict in a `Bool` argument, that argument is still passed
 boxed.  But it could very sensibly be passed unboxed instead, just as we
 do with pairs, say.  So perhaps strictness analysis would work well with
 unboxed enumerations.

 But it's not entirely obvious that it will.  Unboxing a pair is great
 because the pair is never allocated.  But enumerations are never allocated
 either!  (`True` and `False` are statically allocated.)  Moreover, even
 though passing `True` passes a pointer to a (statically allocated) heap
 object, the True/False tag is in the ''pointer'' (see
 [http://research.microsoft.com/en-us/um/people/simonpj/papers/ptr-
 tag/index.htm Faster laziness using dynamic pointer tagging]), so no
 memory access is needed when discriminating True/False.  So the gains from
 unboxing may be modest.

 Pointer tagging only works for data types with a handful of constructors.
 Big enumerations really do keep the tag in memory.  (See the paper.)

 None of this is to say it's a bad idea.  Just that we need clarity about
 where the gains are going to come from, and measurements that suggest the
 gains are real.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler