Comments on: Trends in Profiling Haskell http://blog.downstairspeople.org/2009/04/16/trends-in-profiling-haskell/ A blog of fleshlings and robots. Wed, 25 Jan 2012 12:18:41 +0000 hourly 1 http://wordpress.com/ By: sclv http://blog.downstairspeople.org/2009/04/16/trends-in-profiling-haskell/#comment-23 Fri, 17 Apr 2009 15:23:42 +0000 http://blog.downstairspeople.org/?p=68#comment-23 Maybe -fdicts-cheap?

http://www.haskell.org/pipermail/cvs-ghc/2006-July/030092.html

]]> By: Lane http://blog.downstairspeople.org/2009/04/16/trends-in-profiling-haskell/#comment-22 Fri, 17 Apr 2009 13:46:07 +0000 http://blog.downstairspeople.org/?p=68#comment-22 That’s interesting about the logfloat package. I hadn’t seen that. My concern, however, is not that I don’t know what to do with an errant realToFrac when I find it, but that I keep finding them.

I’m imagining that there may be tens of haskell programs out there that have never been profiled, that run in twice or worse the time they should

]]> By: wren ng thornton http://blog.downstairspeople.org/2009/04/16/trends-in-profiling-haskell/#comment-21 Fri, 17 Apr 2009 05:44:21 +0000 http://blog.downstairspeople.org/?p=68#comment-21 You should consider using Data.Number.RealToFrac from the logfloat package[1]. It gives a class for defining specialized implementations of realToFrac (aka fromRational . toRational) and defines highly optimized instances for the usual suspects.

I don’t have any fusion rules (since the optimized versions are more correct than the Prelude version, and therefore not equal to the composition), which may be where you’re issues are coming up. Though you could probably write your own if you’re not over-cautious about making sure your program transformations are exact.

[1] http://hackage.haskell.org/packages/archive/logfloat/0.12.0.1/doc/html/Data-Number-RealToFrac.html

]]>