Date: Mon, 20 Feb 2023 22:42:31 -0500
On 2/20/23 22:17, Thiago Macieira via Std-Proposals wrote:
> On Monday, 20 February 2023 17:42:59 PST Phil Bouchard via Std-Proposals
> wrote:
>> Although it's not happening with smaller buffers, I suspect Windows uses
>> different heaps based on their size but the large page heaps are
>> definitely faulty.
>
> Don't suspect. Prove it.
>
> This is the entire problem with this thread: you're suspecting a problem and
> jumped to a conclusion that is unwarranted by the facts presented. We've
> already twice shown that the problem was not where you thought it was, meaning
> it's very hard to take any argument you're making on trust alone now. You're
> oh-for-two now; you want a "third time is the charm" case, not "strike three"
> (mixing my metaphors here).
>
> Plus, even if your root-causing of the issue had been right, you've not yet
> demonstrated how your proposed solution would fix anything.
>
> This is in spite of the fact that you can already do what you're proposing to
> do, without the need for a modification to the standard.
Like I was saying privately:
Apparently Visual Studio indeed defaults to x86 which is 32 bits (even
in 2023)...
Again I don't think optimizing further the memory allocator under
Windows is worth the efforts when it is already possible under Linux.
So anyway thanks for the feedback and at least I know now about that
obscure solution under Linux.
> On Monday, 20 February 2023 17:42:59 PST Phil Bouchard via Std-Proposals
> wrote:
>> Although it's not happening with smaller buffers, I suspect Windows uses
>> different heaps based on their size but the large page heaps are
>> definitely faulty.
>
> Don't suspect. Prove it.
>
> This is the entire problem with this thread: you're suspecting a problem and
> jumped to a conclusion that is unwarranted by the facts presented. We've
> already twice shown that the problem was not where you thought it was, meaning
> it's very hard to take any argument you're making on trust alone now. You're
> oh-for-two now; you want a "third time is the charm" case, not "strike three"
> (mixing my metaphors here).
>
> Plus, even if your root-causing of the issue had been right, you've not yet
> demonstrated how your proposed solution would fix anything.
>
> This is in spite of the fact that you can already do what you're proposing to
> do, without the need for a modification to the standard.
Like I was saying privately:
Apparently Visual Studio indeed defaults to x86 which is 32 bits (even
in 2023)...
Again I don't think optimizing further the memory allocator under
Windows is worth the efforts when it is already possible under Linux.
So anyway thanks for the feedback and at least I know now about that
obscure solution under Linux.
-- Logo <https://www.fornux.com/> *Phil Bouchard* facebook icon <https://www.linkedin.com/in/phil-bouchard-5723a910/> CTO T: (819) 328-4743 E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com> 8 rue de la Baie| Gatineau (Qc), J8T 3H3 Canada Banner <https://goglobalawards.org/> Le message ci-dessus, ainsi que les documents l'accompagnant, sont destinés uniquement aux personnes identifiées et peuvent contenir des informations privilégiées, confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message par erreur, veuillez le détruire. This communication (and/or the attachments) is intended for named recipients only and may contain privileged or confidential information which is not to be disclosed. If you received this communication by mistake please destroy all copies.
Received on 2023-02-21 03:42:33