jeremy.shaw:

At Tue, 27 Mar 2007 23:10:21 +0200, Fawzi Mohamed wrote:

...

If someone has an idea on how else I can improve timings please tell me.

I believe you are seeing a speed decrease, because GHC is not inlining functions as much when you split them into modules. If you add explicit inline statements, I think you should be able to get back to your original timings.

Below is an example of how to add INLINE statements.

someFunction :: (Word8 -> Maybe Word8 -> Bool) -> B.ByteString -> B.ByteString someFunction = ... {-# INLINE someFunction #-}

I am not sure what the downsides are. It probably makes the resulting binary bigger, and takes longer to compile. Though, probably not any worse than if you just put everything in one module?

It might be the case that you only need to INLINE one or two functions to get most of the speed back.

Yes, INLINE and compile with -O2. -- Don

Thanks ! Il giorno Mar 28, 2007, alle ore 12:04 AM, Tim Chevalier ha scritto:

On 3/27/07, Jeremy Shaw wrote:

...

At Tue, 27 Mar 2007 23:10:21 +0200, Fawzi Mohamed wrote:

...

If someone has an idea on how else I can improve timings please tell me.

I believe you are seeing a speed decrease, because GHC is not inlining functions as much when you split them into modules. If you add explicit inline statements, I think you should be able to get back to your original timings.

It could be inlining or it could be other optimizations. From the data the OP gives, I don't think it's possible to conclude which ones.

I did longer runs (all compiled with -O2 as before) with the same results. and indeed with a couple of {-# INLINE function #-} I was able to recover the previous performance and actually even get a better performace than before. Thanks! An interesting thing is that the profiler actully was saying that the non inlined version (and for the matter also the the split version) were faster than the inlined or single module versions. It would seem that the profiling ovehead for the inlined functions are not correctly accounted for, so that they appear as more expensive than the plain version when profiling. Fawzi

| I believe you are seeing a speed decrease, because GHC is not inlining | functions as much when you split them into modules. If you add | explicit inline statements, I think you should be able to get back to | your original timings. 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). Simon

http://www.cs.utah.edu/~hal/HAllInOne/index.html On 3/27/07, Derek Elkins wrote:

Fawzi Mohamed wrote:

...

I decided to cleanup my program by splitting it in different modules. As I was curious about the cost of splitting it, or dually the efficiency of the intermodule optimization I timed it before and after the split. These are the results (ghc-6.6.20070129 on Linux AMD64):

A long long time ago, Hal Daume III made Haskell All-in-one which takes a Haskell program and puts all the modules into one file. The difference in efficiency was discussed on one of these mailinglists then. Google should be able to turn up something (albeit it seems to no longer index the haskell.org mailinglists directly). _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Ricardo Guimarães Herrmann "Any sufficiently complicated C or Fortran program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp" "Any sufficiently complicated Lisp or Ruby program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Haskell"