Skip to content

Conversation

@frederick-vs-ja
Copy link
Contributor

@frederick-vs-ja frederick-vs-ja commented Apr 26, 2025

As shown by the comment below, the _Small data member of binomial_distribution is unused, so it's unnecessary to call _Init. Given there's a default member initializer of _Small_poisson_distribution's _Gx0 added in #5411, there won't be uninitialized object even when all explicit operations are skipped.

Also changes the name of binomial_distribution::param_type::_Init to _Init_v2 to avoid potential mix-and-mismatch bugs.

_Sqrt = _CSTD sqrt(2 * _Mean * (1 - _Pp));
_Logp = _CSTD log(_Pp);
_Logp1 = _CSTD log(1.0 - _Pp);
_Small._Init(_Mean);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure. If it was used in some before version, and there's compiled code with that STL that takes already constructed distribution, there will be a bug.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh... the potentially buggy combination seems avoidable by renaming _Init. Although I have no idea whether it could really happen.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there is such problem, I don't believe that the renaming would suffice this time

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what the exact problem is. Did you mean that newly created _Small subobjects will still be processed by legacy compiled code, so data consistency (not only function definitions) needs to be kept?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this. And I mean the whole ..._distribution objjects.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_Small became unused after @MattStephanson's #1531 was merged on 2021-02-12 in VS 2019 16.10.

Renaming _Init to _Init_v2 helps prevent one category of mix-and-match problems. @AlexGuteniev is additionally correct that it doesn't entirely prevent problems. Consider the scenario where a new binary (e.g. user.exe) is compiled with this PR (18.0+) and passes a binomial_distribution to a very old binary (e.g. library.dll) that was compiled pre-#1531 (VS 2019 16.9 or earlier, including all VS 2017 and VS 2015). Then the new binary won't initialize _Small, but the very old binary will try to use it.

_Small_poisson_distribution::_Init sets _Gx0 = _CSTD exp(-_Mean0); so the new data member initializer of _Ty1 _Gx0 = 0.0; is not sufficient.

On the one hand, this is a pretty big span of time - users would have to be mixing code across 4+ years. As long as nothing older than the last supported release of VS 2019 16.11.x is used (including all VS 2022), then #1531 is always present. And it seems uncommon for a binomial_distribution to be passed around, or even stored as a data member; it's much more likely to be used as a local variable, which makes mismatch harder.

On the other hand, this is technically an ABI break, and it's not a major performance win. The risk is (IMO) quite small but the reason to take the risk is also small. We could very very likely get away with it (99.99%) but since we've noticed it, I think the correct thing to do is to avoid merging this.

If this increased correctness, with the same low risk of mix-and-match issues, then I would say that the correctness fix would be worth the risk, but not for a minor performance improvement.

(I observe that #1531 was a correctness improvement itself, so any pre-#1531 code that was activating the _Small codepath wasn't getting very good quality, and really ought to be rebuilt with #1531. However, "low quality" is different from "utterly broken". If pre-#1531 code were utterly broken then I wouldn't worry about mismatch here.)

@StephanTLavavej StephanTLavavej added the performance Must go faster label Apr 27, 2025
@StephanTLavavej StephanTLavavej self-assigned this Apr 27, 2025
@StephanTLavavej
Copy link
Member

Thanks for looking into this. Closing without merging as this is an ABI break that I see no way to cure without introducing "would _Small have been used" branches. See my reply #5442 (comment) for more analysis.

@github-project-automation github-project-automation bot moved this from Initial Review to Done in STL Code Reviews Apr 28, 2025
@frederick-vs-ja frederick-vs-ja deleted the small-zero-init branch April 29, 2025 00:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

performance Must go faster

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

3 participants