[Haskell-cafe] Profiling nested case
mmitar at gmail.com
Sat Jul 12 16:49:20 EDT 2008
> My guess is that it was premature optimization that created this bug.
It is the root of all evil. ;-)
> Unboxed tuples are not the best answer for every situation. They are
> evaluated strictly!
Then I have not understood the last paragraph correctly:
Oh, no. It is like you say. I also use -funbox-strict-fields and Q is
defined with strict fields. But I tried also without the switch and is
it the same (it takes forever). But then qN and qN' does not have
unboxed types. So it should be lazy?
> If you are in that phase where you are doing performance tweaks and
> you think GHC's strictness analysis might not be picking up on some
> strict behavior in your program, add the annotation. If it makes it
> faster, great; if it doesn't change things, take it out! Best to
> underconstrain your program.
I completely agree. I am also a firm believer in the clean and pure
code where I would leave all optimization to compiler and just write
semantics into a program. But this project just showed me that there
is still a long way of compiler development before that would be
possible (and usable). That some simple refactoring of code which is
not really changing semantics have a big influence on a performance
because compiler uses it differently (polymorphic types instead of
hardcoded types, passing function as an parameter instead of hardcode
For example I have now defined my types as:
type BasicReal = Double
data Quaternion = Q !BasicReal !BasicReal !BasicReal !BasicReal
So that I can easily change the type everywhere. But it would be much
nicer to write:
data Quaternion a = Q !a !a !a !a deriving (Eq,Show)
Only the performance of Num instance functions of Quaternion is then
More information about the Haskell-Cafe