Int vs Word performance?

[Don Stewart]

claus.reinke:
>>> Here is a trivial example with drastic difference between
>>> T = Int and T = Word (~2.5x here):
>>>
>>>    main = print $ foldl' (+) 0 [1..100000000::T]
> ..
>>>    GHC.Prim.word2Int#
>>>        (GHC.Prim.and#
>>>            (GHC.Prim.int2Word# wild13_XbE)
>>>            (GHC.Prim.int2Word# y#_a4EZ))
>>>
>>> Is that likely to cost me a lot or are these conversions cheap?
>>
>> Those guys are no-ops, and in general you should never see a performance
>> difference. If you do, it is a bug!  There are some known cases where
>> rules are missing however:
>
> Thanks, that is one thing less to worry about. Btw, is there a "guide to
> reading Core" somewhere, with emphasis on performance aspects (what
> to look for when optimizing time or space usage, what to ignore, how to
> make it more readable, etc)?
>
> Until I stumbled over CORE annotations, I found it near impossible even
> to find the pieces of interest for non-trivial programs, things like
> -dsuppress-uniques help a little with diffs, some things look big but
> are noops, etc. - that kind of helpful pragmatic knowledge (why does
> it look as if source variable names aren't always preserved; why does
> it use random uniques instead of de Bruijn-style disambiguation, which
> wouldn't interfere with diffs and would have static semantic content;
> why do the outputs look different for core2core vs dump-simpl, ..).
>
>> Some others I'm aware of are product/sum/maximum/minimum
>> on lists have specialisations for some atomic types (Int, Integer) but
>> not all (needs a ticket for this too).
>
> A quick grep shows almost no specialization at all for Word, or for
> IntXX/WordXX (see below). Still, none of that seems to explain the
> example repeated at the top of this message.

We do need to decide on if we want to add specializations for all atomic
types in general, and if so, then let'd do that intentionally.

Does anyone see a reason not to do it in the libraries, via rules?