Date: Mon, 27 Mar 2023 12:32:45 -0400
On 3/27/23 08:56, Marcin Jaczewski wrote:
> pon., 27 mar 2023 o 09:17 Phil Bouchard via Std-Proposals
>
> And how is this related to "set_new_handler extension"?
> Besides, if a program "crashes" then in 99.99% cases it is the fault
> of the programmer.
> Especially again you did not check how exactly it "crashes".
> I suggest cleaning the CPU fan on your PC because it could overheat.
I could easily figure it out with Clang's memory sanitizer in Linux but
under Windows we can't compile CUDA using Clang.
>> Under Linux I run the exact same code more aggressively with no
>> optimization and using 12 continuous threads and it never crashes.
>>
>
> And this is a problem as lack of optimization can change endresults.
> Besides if starve system resources then Win and Linux can behave differently.
>
>> Unfortunately there is no big time memory sanitizer under Windows so I
>> still don't have a proof but if it looks and quacks like a duck then it
>> must be a duck.
>>
>
> it must be nastal demons.
>
> And even in 1 of 100000000 cases you did find a bug in Windows,
> how can it even be related to ISO C++ standard??
My initial goal was to integrate some virtual table-based allocator so
we could overwrite the system one on an application basis. It turned out
the idea might be not trivial to implement in Microsoft Windows' system
DLLs.
The benefits of overwriting the allocator could not only imply
robustness but speed as well for low-latency algorithms:
https://github.com/philippeb8/cplusplus-overload-new
> You could have same behavior in C, Rust, Python, C#, Pascal or any other
> language that is used on windows.
>
> Go to Microsoft and ask them to fix it.
Last time I talked to them they embraced and extended my PowerCalc into
their MS Power Toys, so I'd rather do it the correct way from now on.
>> I don't want to reopen this debate, but I was definitely on the right track.
>>
>> --
>> 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.
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> pon., 27 mar 2023 o 09:17 Phil Bouchard via Std-Proposals
>
> And how is this related to "set_new_handler extension"?
> Besides, if a program "crashes" then in 99.99% cases it is the fault
> of the programmer.
> Especially again you did not check how exactly it "crashes".
> I suggest cleaning the CPU fan on your PC because it could overheat.
I could easily figure it out with Clang's memory sanitizer in Linux but
under Windows we can't compile CUDA using Clang.
>> Under Linux I run the exact same code more aggressively with no
>> optimization and using 12 continuous threads and it never crashes.
>>
>
> And this is a problem as lack of optimization can change endresults.
> Besides if starve system resources then Win and Linux can behave differently.
>
>> Unfortunately there is no big time memory sanitizer under Windows so I
>> still don't have a proof but if it looks and quacks like a duck then it
>> must be a duck.
>>
>
> it must be nastal demons.
>
> And even in 1 of 100000000 cases you did find a bug in Windows,
> how can it even be related to ISO C++ standard??
My initial goal was to integrate some virtual table-based allocator so
we could overwrite the system one on an application basis. It turned out
the idea might be not trivial to implement in Microsoft Windows' system
DLLs.
The benefits of overwriting the allocator could not only imply
robustness but speed as well for low-latency algorithms:
https://github.com/philippeb8/cplusplus-overload-new
> You could have same behavior in C, Rust, Python, C#, Pascal or any other
> language that is used on windows.
>
> Go to Microsoft and ask them to fix it.
Last time I talked to them they embraced and extended my PowerCalc into
their MS Power Toys, so I'd rather do it the correct way from now on.
>> I don't want to reopen this debate, but I was definitely on the right track.
>>
>> --
>> 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.
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
-- 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-03-27 16:32:47