Re: Summary of containers patches

On 24/09/2010 05:26, Don Stewart wrote:

bos:

...

On Thu, Sep 23, 2010 at 6:17 PM, Don Stewart 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