container<POD> refactoring

[Gabriel Dos Reis]

Joe Buck <Joe.Buck@synopsys.COM> writes:

| On Mon, Sep 20, 2004 at 01:28:00PM -0500, Gabriel Dos Reis wrote:
| > Joe Buck <Joe.Buck@synopsys.COM> writes:
| > 
| > | Has anyone done any thinking about adding specializations for avoiding
| > | bloat with containers of POD types?  For std::vector, it seems that all
| > | of the out-of-line functions other than the == and < operators depend
| > | only on the size of the POD, and nothing else.
| > 
| > I would say this is something best done at the linker level.
| > User-codes may detect -- at program source level -- whether we
| > specialize or not.
| 
| The linker could resolve cases where the exact same code is generated.
| However, relying on that has two limitations:

I guess they are limitations we'd have to live with, or improve on.

| - While the exact same code will work, the compiler may not generate the
|   exact same code.  Consider vector<int> vs vector<float>.  The latter
|   might generate floating point copies for insertion functions.

Yes, and in such cases, implementing sharing at the library source
would not help either.

| - Some opportunities for refactoring are missed.  For most of these
|   functions, the same code could handle PODs of different sizes with
|   nearly no penalty (the __insert_aux function for a POD of four bytes
|   and a POD of eight bytes is basically the same; at some point there
|   is a multiplication by the size).

That depends on the assumption that our optimizers  and inliners  are
effective.  An assumption that I would not depend on, since the
inliners nowadays typically think know better than the programmer.

| - Speed penalty (though I don't know if this is significant).  If we
|   can avoid expanding, compiling, and then discarding function bodies
|   for many STL functions in common cases, there may be a speedup; this
|   has to weigh against the extra cost of parsing extra specializations,
|   of course.

and optimizing out extra junks.  That last point defintely would need
measurements, irrespective of the previous points.

-- Gaby