[Bug libstdc++/51653] New: More compact std::tuple

[Bug libstdc++/51653] New: More compact std::tuple

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51653

             Bug #: 51653
           Summary: More compact std::tuple
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: marc.glisse@normalesup.org


Created attachment 26166
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26166
proof of concept

Hello,

as a low priority enhancement possibility, I think it would be nice if
std::tuple was more compact. This would allow people to just use tuple<field1,
field2,field3> instead of having to think about the likelihood of the size of
each field to get a good layout. For instance, sizeof(tuple<char,int,char>)
could be 2*sizeof(int) (on platforms where sizeof(int)>1) instead of the
current 3*sizeof(int) by reordering internally as int,char,char. Empty fields
could all be moved to the beginning to avoid problems with
tuple<Empty,Empty,int> having size 2*sizeof(int) (an ABI weirdness).
Independently, derivation could be used more often for _Head_base (not final
and not virtual? more restrictions?) so that tuple<char,tuple<char,int>> has
only size 2*sizeof(int) (note that this kind of compression won't happen for
POD).

The main drawback is that it will complicate code. In many cases, tuple is just
used as an intermediate (forward_as_tuple followed by get) and we don't care
about the tuple layout, so it would needlessly slow down compilation and, as
any complication, it might hinder some flaky optimizations.

There are 2 main ways to implement this.
- a compiler intrinsic could be created that asks the compiler to reorder bases
for a dense layout (suggested by Jonathan Wakely). Note that this is not pragma
pack, as things should remain properly aligned.
- a pure library solution is possible too. I am attaching a proof of concept. I
know my code tends to be unreadable, but it shows that, taking out the ordering
function, the remaining tuple code can be fairly simple (mytuple__ is 6 lines,
the body of myget is 1 line, and the rest is implemented on top without needing
to know how the basis is implemented). Obviously I didn't implement the whole
interface.

[Bug libstdc++/51653] More compact std::tuple

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51653

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-22 12:57:06 UTC ---
Neat! Thanks for demonstrating this. I'm not yet convinced we want to apply it,
but it's nice to know it can be done without *too* much trouble.

[Bug libstdc++/51653] More compact std::tuple

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51653

--- Comment #2 from Marc Glisse <marc.glisse at normalesup dot org> 2011-12-24 22:25:51 UTC ---
(In reply to comment #1)
> I'm not yet convinced we want to apply it,

Hi,

just so I know, what part are you not convinced about?
1) that we want a library solution? it is just a proof of concept, I would be
happy with a compiler solution (although it might still require a library
rewrite so it can be applied).
2) that we want a more compact tuple? sizeof(tuple<char,tuple<char,int>>) is
currently 16, that's twice as much as necessary (in case someone wonders, the
unexpected extra 4 is there for the same reason that tuple<tuple<tuple<int>>>
has size 12, ie derivation from the empty tuple<>).

Note that it is not obvious how to efficiently (you can't try all n! orders...)
determine the best layout. In the code I just put all the empty types first and
then the rest sorted by decreasing alignment, but that heuristic is not optimal
for several reasons:
- there can be hidden empty types in the bigger types
- if we use derivation also for non-empty types, the size (without tail
padding) is not a multiple of the alignment anymore and the heuristic doesn't
make much sense anymore.

[Bug libstdc++/51653] More compact std::tuple

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51653

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ABI
                 CC|                            |glisse at gcc dot gnu.org

--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> 2012-08-22 20:23:46 UTC ---
The suggestion in this PR is quite wild, but the fact that
sizeof(tuple<tuple<tuple<tuple<tuple<int>>>>>)==20 is a real issue that could
probably be solved with less trouble (still ABI-breaking). Maybe I should have
split the PR...

[Bug libstdc++/51653] More compact std::tuple

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51653

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #3)
> The suggestion in this PR is quite wild, but the fact that
> sizeof(tuple<tuple<tuple<tuple<tuple<int>>>>>)==20 is a real issue that
> could probably be solved with less trouble (still ABI-breaking). Maybe I
> should have split the PR...

That's fixed by the patch attached to PR56785

[Bug libstdc++/51653] More compact std::tuple

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51653

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Is there anything more to do for this?

[Bug libstdc++/51653] More compact std::tuple

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51653

--- Comment #6 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #5)
> Is there anything more to do for this?

Yes. This PR is about having the library reorder the elements of a tuple to
minimize the size, and the current code does not do anything like that. Now
this would be an ABI break, and even if it wasn't we might not want to do that,
so it is ok if a libstdc++ maintainer decides to close it as wontfix.

[Bug libstdc++/51653] More compact std::tuple

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51653

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-12-06
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
We should do it for the --enable-symvers=gnu-versioned-namespace build.

It's just not a priority for me right now.

[Bug libstdc++/51653] More compact std::tuple

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51653

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #7)
> We should do it for the --enable-symvers=gnu-versioned-namespace build.

s/should/could/

If it makes the implementation diverge too much (and requires support
elsewhere, like std::get and std::tuple_element) maybe it's not worth it. But I
don't think we've concluded it's WONTFIX yet.