Summary of containers patches
marlowsd at gmail.com
Fri Sep 24 05:30:55 EDT 2010
On 24/09/2010 05:26, Don Stewart wrote:
>> 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.
More information about the Libraries