Summary of containers patches

[Simon Marlow]

On 24/09/2010 05:26, Don Stewart wrote:
> bos:
>> On Thu, Sep 23, 2010 at 6:17 PM, Don Stewart<dons at galois.com>  wrote:
>>
>>      Well, I still don't understand what penalty the code bloat is exactly.
>>
>> It's going to push I-cache misses through the roof when there are umpteen
>> identical versions of the same function over Map ByteString Foo. Also, some of
>> us would like to ship applications written in Haskell, and network bandwidth is
>> a big concern there, having gone nowhere in years.
>
> Reducing binary sizes via dynamic linking is going to make a lot more of
> an impact than dditional unrolling. However, we have *no* other
> techniques for making containers faster.
>
> Perhaps a containers-inline fork is needed, for those who still need the speed.

I absolutely agree that speed is important, and speed by default is a 
valuable property to have.  The recent work on containers will be a 
tremendous benefit to the community.

Having said that, I'm not keen on forcing functions to be inlined at 
every call site: it takes away the choice from the user, and I like 
users to be able to tweak the tradeoff between code size and speed. 
This is the great thing about INLINABLE: it defers the choice to the 
client.  Unfortunately it seems that these functions are just too big 
for GHC to consider worth inlining - GHC is quite conservative about 
code bloat with its default settings.

You can already tweak the tradeoff yourself with 
-funfolding-use-threshold100, but perhaps we need a more accessible, 
user-friendly way to do this, such as -O3.  We don't need a fork of the 
containers package - just tell users that they need to turn up the knob 
to get better performance.

I'm not sure if we should be basing all our decisions on measurements 
done with Map Int.  Clients using Map Int can already get a huge speed 
boost by switching to IntMap.  Let's use something more realistic like 
Map ByteString or Map Integer with some big Integers.

Cheers,
	Simon