simonmarhaskell at gmail.com
Thu Jan 3 04:40:04 EST 2008
Isaac Dupree wrote:
> nativeGen/MachRegs uses unboxed tuples to contain FastInts, which may be
> 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
> 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
> 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.
Agreed. It's very difficult to test whether a particular change degrades
performance, as it might only do so on certain examples.
The best approach is to try to isolate the compiler-specific code as much
as possible - for example having compiler-specific implementations of
(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?)
> 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.
More information about the Cvs-ghc