#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