Boost logo

Boost :

Subject: Re: [boost] [review] Heaps
From: Andrew Sutton (asutton.list_at_[hidden])
Date: 2011-06-02 10:41:43


> I forward here some comments from CC requested by Andrew
>
> "VE:    How the objects per page impact the behavior/performances of the
> b_heap?
> AS:     I think that there may be a serious design flaw here. The number of
> objects per page should depend on the size of the object--much like the
> implementation of deque.
>
> I think that you should be able to find a function that derives this value
> based on the size of the object and the cache properties of the host
> machine. A non-trivial, but I think important feature.
>
> This discussion should be elevated to the mailing list.

In retrospect, "serious design flaw" is not a good description for
this issue :) but I think that this is important to address.

I was going to bring this up today. My suspicion is that allowing
users to freely specify the number of objects per page could lead to
performance degradation if they choose unwisely. I further suspect
that you can formulate some heuristic that optimizes choice size of
the object. I'd look at GCC's deque and see what what's going on
there. LibC++ takes employs a similar heuristic.

Cache properties will also impact performance related to this choice,
but I think that information is not always available at compile time.
Also, I think that cache properties matter more as the size of the
heap gets large, so it may not

I'm not fundamentally opposed to allowing customization of this
parameter (in order to support experimentation), but I think that the
default value should be derived differently. Also, the documentation
must explain why the parameter might be varied, and in general why it
should not.

Andrew


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk