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
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
