#601: Replace GMP
---------------------------------+------------------------------------------
Reporter: simonmar | Owner:
Type: task | Status: new
Priority: normal | Milestone: _|_
Component: Compiler | Version: None
Severity: normal | Resolution: None
Keywords: | Difficulty: Difficult (1 week)
Testcase: N/A | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
---------------------------------+------------------------------------------
Comment (by igloo):
Replying to [comment:9 igloo]:
>
> However, the attached base.html (comparing nofib runs with GMP and
integer-simple) makes me think that that is infeasible
I did some digging to find out what was going on. Using an instrumented
`integer-gmp`, it turned out that, during a build of GHC, there were
7,312,684 calls to `GHC.Integer` that returns a `J#` result. Of these,
4,479,189 were calls to `decodeFloat`, and 2,804,132 were calls to
`quotRem`. This is because functions like `round` call `properFraction`,
which looked like this:
{{{
properFraction x
= case (decodeFloat x) of { (m,n) ->
let b = floatRadix x in
if n >= 0 then
(fromInteger m * fromInteger b ^ n, 0.0)
else
case (quotRem m (b^(negate n))) of { (w,r) ->
(fromInteger w, encodeFloat r n)
}
}
}}}
where `m` and `n` are `Integer`s (and always `J#`, despite never being big
enough to need to be).
In the HEAD this has now been rewritten to use `Int` rather than
`Integer`, so all of those `J#` integers disappear (we're also looking at
reducing the number of `round` calls we make, but that no longer affects
this ticket).
There are now only 28,741 calls returning `J#` integers; 22,306 of them
are `wordToInteger` calls, which are very cheap with simple-integer (which
builds `Integer`s out or `Word#`s).
Division is probably the slowest operation with simple-integer, so it
seems likely that this was the cause of the slow-down. We should do some
new timings to see where we stand.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/601#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
