[Haskell-cafe] Profiling nested case

[Mitar]

Hi!

> 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:

http://www.haskell.org/ghc/docs/latest/html/users_guide/primitives.html

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
it).

For example I have now defined my types as:

type BasicReal = Double

data Quaternion = Q !BasicReal !BasicReal !BasicReal !BasicReal
deriving (Eq,Show)

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
quite worse.


Mitar