
ehm, never post from someone's else computer with a new mailer... sorry for the double posts (to glasgow-haskell-users@haskell.org and here). Simon Peyton-Jones wrote:
Generally speaking GHC will inline *across* modules just as much as it does *within* modules, with a single large exception.
If GHC sees that a function 'f' is called just once, it inlines it regardless of how big 'f' is. But once 'f' is exported, GHC can never see that it's called exactly once, even if that later turns out to be the case. This inline-once optimisation is pretty important in practice.
So: do not export functions that are not used outside the module (i.e. use an explicit export list, and keep it as small as possible).
This is very interesting to know, as it explains a strange effect that I was seeing: I had an algorithm and I began to add variants of it as separate functions in the same module. Then I saw the original function (which I had not touched) get slower and slower. I even wondered if the compiler was not maybe taking common parts of my functions out of them to reduce the evaluations making my original function slower, but then it was that it wasn't inlining anymore some functions. This means the with haskell (with ghc) cleaning up old code and keeping the modules as clean as possible pays off even more than in other languages... good to know, and very important when benchmarking various algorithms: commenting out a variant is better as having it as separate function.... Fawzi

Fawzi Mohamed wrote:
good to know, and very important when benchmarking various algorithms: commenting out a variant is better as having it as separate function....
Yes, but don't get over-paranoid. The 'overhead' of calling as opposed to inlining is relatively small, and only matters if the function concerned is being called many many times in your inner loop. Jules

Jules Bean wrote:
Fawzi Mohamed wrote:
good to know, and very important when benchmarking various algorithms: commenting out a variant is better as having it as separate function....
Yes, but don't get over-paranoid. The 'overhead' of calling as opposed to inlining is relatively small, and only matters if the function concerned is being called many many times in your inner loop.
Jules Yes, but when benchmarking numerical algorithms you probably have such a situation, my code went from 6.5 s to 8.0 s, without touching it, just adding extra functions. This was not something I had expected, and now, thanks to Simon's comment I understand it.
I still wonder if some "common expression elimination" did not kick in, well I guess In the future I should really take a look to the Core output, as Don suggested, but I am still trying to avoid it :-)... Fawzi
participants (2)
-
Fawzi Mohamed
-
Jules Bean