Date: Mon, 27 Mar 2023 03:17:41 -0400
On 2/21/23 00:05, Thiago Macieira wrote:
> On Monday, 20 February 2023 19:31:16 PST Phil Bouchard wrote:
>>> Don't suspect. Prove it.
>>
>> Prove what? Windows' code is proprietary.
>
> You don't need access to the source to prove the point. You just have to have
> a working application that, when run, shows the problem and has no reasonable
> other reason for having the behaviour in question than what your hypothesis
> is.
>
>>> 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).
>>
>> I just explained it crashes on both Windows 10 and 11 with 28x and 16x
>> Intel Core i9 using Visual Studio 2019 in 64 bits Release mode.
>
> And as your later email has just shown, the problem wasn't the allocator; it
> was that your application exhausted the address space of a 32-bit application
> (which on Windows is 2 GB; on 32-bit Linux it used to be 3 GB and in a 64-bit
> Linux kernel, the 32-bit application gets all 4 GB).
>
> You've twice now shown an application that fails to run for a reason that was
> not what you thought it was. Your hypothesis remains unproven.
So I did try all form of optimizations of OpenCV on Windows (TBB, Intel
IPP, OCL, ...) running just 3 intermittent threads synced every 33
milliseconds and the same cv::threshold function crashes before 3 hours.
The function is readonly also except from the resulting object!
Under Linux I run the exact same code more aggressively with no
optimization and using 12 continuous threads and it never crashes.
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.
I don't want to reopen this debate, but I was definitely on the right track.
> On Monday, 20 February 2023 19:31:16 PST Phil Bouchard wrote:
>>> Don't suspect. Prove it.
>>
>> Prove what? Windows' code is proprietary.
>
> You don't need access to the source to prove the point. You just have to have
> a working application that, when run, shows the problem and has no reasonable
> other reason for having the behaviour in question than what your hypothesis
> is.
>
>>> 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).
>>
>> I just explained it crashes on both Windows 10 and 11 with 28x and 16x
>> Intel Core i9 using Visual Studio 2019 in 64 bits Release mode.
>
> And as your later email has just shown, the problem wasn't the allocator; it
> was that your application exhausted the address space of a 32-bit application
> (which on Windows is 2 GB; on 32-bit Linux it used to be 3 GB and in a 64-bit
> Linux kernel, the 32-bit application gets all 4 GB).
>
> You've twice now shown an application that fails to run for a reason that was
> not what you thought it was. Your hypothesis remains unproven.
So I did try all form of optimizations of OpenCV on Windows (TBB, Intel
IPP, OCL, ...) running just 3 intermittent threads synced every 33
milliseconds and the same cv::threshold function crashes before 3 hours.
The function is readonly also except from the resulting object!
Under Linux I run the exact same code more aggressively with no
optimization and using 12 continuous threads and it never crashes.
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.
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.
Received on 2023-03-27 07:17:44