Isaac Dupree wrote:
John Meacham wrote:
Excellent! this has always been a project I wanted to do in the back of my mind. I will likely make it the default Integer implementation for jhc. I look forward to the fun compiler optimizations it will inspire to make it speed comparable to gmp
Actually we have a few advantages over GMP: We can do inlining, and analysis for static knowledge (e.g. small numbers or nonzero numbers), much more than in C, which knows nothing about its bignum type. Probably this would work best with some knowledge baked into the compiler about the meaning of Integer operations (like the way GHC has metadata along with the definitions of its primitives, at least whether they're symmetric operations...) (Unless some way to specify that with compiler pragmas is invented, but computing with Integers may be a bit of a special case.) I want to see compilers do more sophisticated constant folding (generally, computation at compile time), which has to watch out for non-pure, non-safe and non-total (nonterminating) functions as well as deciding whether some partial computation will reduce code size and improve speed, or just bloat it. We can make a higher-level library/type, that relies on any Integer implementation, and gives a type that does not evaluate immediately, so optimizations (runtime) can be done on series of operations. Er... the Integer type would probably have to provide operations that were more efficient and did weird things -- either a Haskell Integer implementation or GMP's mpn layer would probably be useful. (Haskell is a particularly good language for things like this, I think... if it is likely to be useful... It is useful for matrix operations in C++ :)) Another thing I was wondering is whether there's any point making it be able to work on the GMP-integer representation that GHC stores internally... probably not much. Isaac