unboxed types

[Isaac Dupree]

Neil Mitchell wrote:
> Hi Isaac,
> 
>> Or will I have to
>> #define UTopen (#
>> #defined UTclose #)
>>
>> and (UTopen x, y UTclose)
> 
> Yuk! There is a ticket on adding a prefix form of (#,#), which is
> currently lacking. Perhaps adding that first, then moving to the
> unboxed thingy would be best. Also your use of # in a CPP macro may
> confuse various CPP stuff in GHC.

added!

> 
> I'd also be shocked if it turns out that unboxed types make that much
> of a difference. They will make a difference in library functions
> (called a lot), or hot-spots, but in general they only add a constant
> improvement. Of course, numbers are better than speculation - and
> would be interesting in their own right!

nativeGen/MachRegs uses unboxed tuples to contain FastInts, which may be 
unboxed.

nativeGen/AsmCodeGen, nativeGen/RegAllocLinear, and utils/State each use 
unboxed tuples in return values of newtypes that are declared Monads -- 
efficiency of the tuple is the only excuse (not even efficiency of what 
it contains), and I may test how they are with boxed tuples.  On the 
other hand, as far as I can tell, CmmOptM and RegM are really just state 
monads that can and should use utils/State.  No, actually CmmOptM is a 
State/Reader monad... which it's not quite as obvious what to do with.

utf8DecodeChar# in utils/Encoding (defined) and utils/StringBuffer 
(used) has unboxed tuple that contains FastTypes (well, unboxed types, 
but I think I'm going to make a FastChar and FastPtr to allow conversion 
of this kind of code)

The comments make clear that some of these places *are* hotspots (at 
least believed at the time of writing) (nativeGen/MachRegs' 
trivColorable, and utf8DecodeChar -- the monads' unboxed tuples aren't 
mentioned)

The rest of the unboxed-tuple uses are either not part of stage1 code, 
or refer to actual GHC-specific uses such as using the newtype IO 
constructor.

Given these few places, the limitations of past GHCs, and the desire to 
have unoptimized GHC be a decent speed, I think UTopen and UTclose 
macros are probably the best solution.  (opinions?)  Given those macros, 
and my type-class-extension-removal patchset, a GHC stage1 is in sight 
(needs a little more hacking and hack-cleanup on my part before 
submitting, maybe 1 day) that "only" uses CPP, ForeignFunctionInterface, 
PatternGuards and Rank2Types; plus MagicHash, UnboxedTuples and 
importing GHC.*, when __GLASGOW_HASKELL__ is defined.  It might be 
possible that the four modules that use Rank2Types could be refactored 
not to, but that would be no use because GHC also uses module import 
cycles, which neither hugs nor nyhc support.

extension matrix, am I right? (did the tabs work to format it?)
		ghc	n&yhc	hugs	jhc
CPP -- doesn't need compiler support; cabal may help
Rank2Types	yes	no	yes	yes
FFI		yes	yes	yes	yes
PatternGuards	yes	[1]	no	[2]
module-cycles	[3]	no	no	yes
non-bugginess	good	medium	good	poor
(all implementations including GHC probably have bugs affecting this 
however)

Also I the patches I sent for Happy are needed in order to use it 
without any -agc flags.

[1] supported in darcs but not a released version? or was there a recent 
nhc release supporting pattern-guards?
[2] I don't think jhc supports pattern-guards currently, but it should 
be easy to add
[3] GHC requires .hi-boot or .hs-boot files currently, but nyhc and hugs 
don't even have any option like that to allow module cycles?

JHC seems closest (even if something like HAllInOne could deal with 
module cycles, nyhc and hugs each also still have a missing extension 
that might be hard to remedy), and if jhc's instability proves a 
problem, I'll motivate John Meacham with the ability to compile GHC :-) 
(and GHC has a testsuite to check if it's compiled correctly!)

Also JHC supports some unboxed types and tuples, so it's possible they 
could be enabled in FastTypes-areas to augment speed.

hmm... maybe I'll move some of these observations to the Trac ticket 
http://hackage.haskell.org/trac/ghc/ticket/1405 when I'm more organized 
with my patches.

-Isaac