[Haskell-cafe] Re: Importing Data.Char speeds up ghc around 70%

[Simon Marlow]

Joost Behrends wrote:
> Neil Mitchell <ndmitchell <at> gmail.com> writes:
>  
>> If it can be reproduced on anyones machine, it is a bug. If you can
>> bundle up two programs which don't read from stdin (i.e. no getLine
>> calls) or the standard arguments (i.e. getArgs) which differ only by
>> the Data.Char import, and have massive speed difiference, then report
>> a bug.
>>
>> You should probably also give your GHC versions and platforms etc.
> 
> Thanks for your attention too !
> 
> Now i tried a version without input (just computing the primefactors of the
> constant 2^61+1, what it did correctly in spite of its bugginess). And it
> didn't have the Data.Char bug (and Data.List bug) too.
> 
> As my original code hasn't on Linux also it seems.
> 
> Thus it  happens only in an exotic configuration. Windows will stay exotic
> in the Haskell community. Before should noone
> has reproduced it at least on Windows (XPpro SP2 is my version), i will do 
> nothing more.
> 
> The hardware is Intel Celeron 2.2GHZ, 512 MB Ram. ghc 6.8.1 lives on
> D:\\Programme (not on the system drive C:, which poses problems to Cabal, 
> told aside).

Even if it only happens on Windows, if it isn't specific to your hardware 
then it could still be a bug.

I have seen strange artifacts like this before that turned out to be caused 
by one of two things:

  - bad cache interactions, e.g. we just happen to have laid out the code in
    such a way that frequently accessed code sequences push each other out
    of the cache, or the relative position of the heap and stack have a bad
    interaction.  This happens less frequently these days with 4-way and
    8-way associative caches on most CPUs.

  - alignment issues, such as storing or loading a lot of misaligned Doubles

in the second case, I've seen the same program run +/- 50% in performance 
from run to run, just based on random alignment of the stack.  But it's not 
likely to be the issue here, I'm guessing.  If it is code misalignment, 
that's something we can easily fix (but I don't *think* we're doing 
anything wrong in that respect).

I have an Opteron box here that regularly gives +/- 20% from run to run of 
the same program with no other load on the machine.  I have no idea why...

Cheers,
	Simon