Date: Sun, 2 Apr 2023 03:48:29 -0400
On 3/28/23 22:38, Phil Bouchard via Std-Proposals wrote:
>
>
> On 3/27/23 13:01, Thiago Macieira wrote:
>> On Monday, 27 March 2023 12:32:45 EDT Phil Bouchard wrote:
>>> I could easily figure it out with Clang's memory sanitizer in Linux but
>>> under Windows we can't compile CUDA using Clang.
>>
>> Complain to your CUDA vendor. That has nothing to do with the C++
>> standard: if
>> you're using a piece software that you can't modify to your wishes,
>> modifying
>> the C++ standard is not the solution to the problem.
>
> I duly noted that the C++ committee is not interested to integrate this
> into the standards.
>
> That doesn't mean I agree given the standards can make use of some major
> revamp instead of the never ending minor syntax changes here and there.
>
> I also proactively think it's pretty obvious that C++ will need to adapt
> sooner or later to load balanced algorithms using different types of
> parallel processors and memory.
>
> When I think about it the new virtual table-based memory allocator could
> not only be sped up using fast thread-local FIFO memory pages I've
> previously shown (3.6x) but also adding the ability to use CPU or GPU
> memory pages could also be a great asset.
Again, I know the decision is made and I'm not trying to influence the
decision but I just wanted to point out I do have evidence now as I'm
running the exact same code featuring the readonly function
cv::threshold() in multithreaded mode in Linux and it doesn't randomly
crash.
So I was initially right in my suspicions despite all intimidation. I
won't bother Microsoft either because I don't care enough.
Thank you,
>
>
> On 3/27/23 13:01, Thiago Macieira wrote:
>> On Monday, 27 March 2023 12:32:45 EDT Phil Bouchard wrote:
>>> I could easily figure it out with Clang's memory sanitizer in Linux but
>>> under Windows we can't compile CUDA using Clang.
>>
>> Complain to your CUDA vendor. That has nothing to do with the C++
>> standard: if
>> you're using a piece software that you can't modify to your wishes,
>> modifying
>> the C++ standard is not the solution to the problem.
>
> I duly noted that the C++ committee is not interested to integrate this
> into the standards.
>
> That doesn't mean I agree given the standards can make use of some major
> revamp instead of the never ending minor syntax changes here and there.
>
> I also proactively think it's pretty obvious that C++ will need to adapt
> sooner or later to load balanced algorithms using different types of
> parallel processors and memory.
>
> When I think about it the new virtual table-based memory allocator could
> not only be sped up using fast thread-local FIFO memory pages I've
> previously shown (3.6x) but also adding the ability to use CPU or GPU
> memory pages could also be a great asset.
Again, I know the decision is made and I'm not trying to influence the
decision but I just wanted to point out I do have evidence now as I'm
running the exact same code featuring the readonly function
cv::threshold() in multithreaded mode in Linux and it doesn't randomly
crash.
So I was initially right in my suspicions despite all intimidation. I
won't bother Microsoft either because I don't care enough.
Thank you,
-- 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-04-02 07:48:31