This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [libstdc++ PATCH/RFC] Aggressive space optimization for std::vector


On Monday, July 28, 2003, at 1:13PM, Gabriel Dos Reis wrote:

Doug Gregor <dgregor@apple.com> writes:

| There is more that can be done on the micro-optimization level, such
| as eliminating some of the extra overhead in _Vector_impl (e.g., its
| iterators can just be pointers, because they will never be exposed to
| the user). However, I'd like to know if this type of optimization is
| desired in libstdc++. It uglifies the source a bit, but it can be a
| boon to users.

I guess this space optimization may have some impact on code
efficiency (optimization for something else than space).  Did you make
any measurements? I'm worried because GCC currently tends not to
inline even simple accessor -- see past report by Benjamin.

It could have some impact on code efficiency (the deeper call graph and replacement of fundamental types with class types are two potential problems), but I haven't measured this. As I mentioned previously, the patch does introduce code size regressions (albeit small ones) in the no-reuse case, so we are likely losing a little performance here. I'll look to see if I can stamp out those regressions, perhaps by moving away from _Basic_pod.


 Try to
compile with -Winline.

No difference.


It would be nice if this code was rather controlled by -Os.

It's an ABI-breaker, so we can't do that.


Also, I suppose this

!
!   // Primary template has maximum alignment
!   template<std::size_t _Alignment>
!     struct _Type_with_alignment
!     { struct __attribute__((__aligned__)) _M_type {}; };
!
! #define _GLIBCXX_TYPE_WITH_ALIGNMENT(_Align)				\
!   template<>								\
!     struct _Type_with_alignment<_Align> \
!     { struct __attribute__((__aligned__(_Align))) _M_type {}; }

is for getting around the bug in how attributes are handled (I filled
a bug report on that a while ago), i.e. attributes don't respect usual
name lookup rules.  Please add a note to that effect.

I'd really like:
template<std::size_t _Alignment>
struct __attribute__((__aligned(_Alignment))) _Type_with_alignment {};


... but I've just added a note instead.

Also, I would rather see

! template<std::size_t _Size, std::size_t _Alignment>
!   struct __type_traits<std::_Basic_pod<_Size, _Alignment> >
!   {
!     typedef __true_type    has_trivial_default_constructor;
!     typedef __true_type    has_trivial_copy_constructor;
!     typedef __true_type    has_trivial_assignment_operator;
!     typedef __true_type    has_trivial_destructor;
!     typedef __true_type    is_POD_type;
!   };

in the file where the original __type_traits<> is defined.

Ok.


  In the
long run, we should move away from the type based __true_type usage
toward integral constant usage.

We should move to the TR type traits proposal, I think.


Doug


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]