On Tue, 18 Mar 2025 at 15:12, Yongwei Wu <wuyongwei_at_[hidden]> wrote:
>
> On Mon, 17 Mar 2025 at 00:49, Jason McKesson via Std-Discussion
> <std-discussion_at_[hidden]> wrote:
> >
> > On Sun, Mar 16, 2025 at 11:53 AM Giuseppe D'Angelo via Std-Discussion
> > <std-discussion_at_[hidden]> wrote:
> > >
> > > Il 16/03/25 15:48, Jason McKesson via Std-Discussion ha scritto:
> > > > If that's how [[indeterminate]] is expected to work, if it's something
> > > > that most programmers most of the time won't need to think about, then
> > > > I don't think these disadvantages really apply. That is, it is not up
> > > > to the implementer of any particular class as to whether or not
> > > > [[indeterminate]] is appropriate for the class; it's up to the final
> > > > user of that object on a case-by-case basis. They are the ones looking
> > > > for that performance benefit, so they are the ones who get to say when
> > > > to get it.
> > >
> > > Well, there are classes that are entirely made to reap extra performance
> > > benefits; the prime example are the "std::vector<T> with SOO" that exist
> > > in pretty much every codebase. A user chooses those classes instead of
> > > std::vector<T> precisely because they're looking for extra performance.
> > > It's weird to ask them to _also_ annotate such usages with
> > > [[indeterminate]] (... assuming that they're even using such classes
> > > directly. If they're wrapped by another class (class Foo {
> > > SmallBuffer<int> buf; }), then the situation is even clumsier).
> >
> > Using SOO is primarily about memory allocation performance. That is,
> > not allocating heap memory unless you go over a certain size. So while
> > filling those bytes with known values would lower performance relative
> > to not doing so, the performance lost to that completely different
> > level from saving a memory allocation. After all, we're talking about
> > stack memory, which is likely in the cache already.
> >
> > That is, failure to use [[indeterminate]] isn't going to make using
> > such types ineffective as performance optimization tools. That doesn't
> > mean that they may not want to use [[indeterminate]] as well, but I
> > don't think it's something people have to do in order to get
> > acceptable performance?
>
> The problem is that when people do want the best performance (why
> using C++ if one does not need performance?), the current approach
> feels hacky and viral (instead of being principled). Imagine I have an
> efficient implementation of BigString, which includes an uninitialized
> buffer, and I have:
>
> struct A {
> BigString s[10];
> };
>
> struct B {
> A dataA;
> int anotherValue;
> };
>
> struct C {
> B dataB;
> char someThingElse;
> };
>
> …
>
> Efficient use of all A, B, and C objects will require the use of
> [[indeterminate]].
>
> It would be a punishment to people who want to implement Small Object
> Optimization....
>
> SOO implementers never want their users to worry about marking
> objects. They should not need to.
>
> The intention of having erroneous behaviour is not to penalize SOO,
> right? Is erroneous behaviour so good that we do not mind the
> collateral damage to SOO and performance?

Another thing potentially worth noting is that the GCC
-ftrivial-auto-var-init option is quite complicated in its behaviour:

* If optimization is off, all automatic variables are initialized
according to the option.
* If optimization is on, only trivial automatic variables are
initialized. I.e. uninitialized data members of an object that has a
constructor are not initialized in this case.

Anyway, objects that implement SOO will not have penalties when
optimization is on.

Clang's behaviour is different in some subtle details, but it also has
this property: objects that implement SOO will not have penalties when
optimization is on.

That, at least, shows what our compiler vendors consider to be best practices.

-- 
Yongwei Wu
URL: http://wyw.dcweb.cn/