Re: [Openexr-devel] Pulling my hair out: switchingprojecttoVS2008breaks OpenEXR :(

[Chris Cox]

Only once I get the code released as open source. That should happen in the
next few weeks.

Chris



On 10/27/08 6:58 PM, "Nick Porcino" <address@hidden> wrote:

> Could you share a pointer to the benchmarking results?
> 
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Chris Cox
> Sent: Monday, October 27, 2008 4:38 PM
> To: address@hidden
> Subject: Re: [Openexr-devel] Pulling my hair out:
> switchingprojecttoVS2008breaks OpenEXR :(
> 
> I have some nice benchmarks that put the penalty at 200 to 3000 percent.
> (one version of it was recently posted to the boost mailing list, I hope
> to
> have it with the rest of my open source benchmarks soon).
> 
> I guess actually using vector is an "unusual" case for them.
> 
> No, their overhead is too high even for debug builds.  Of course, that
> could
> be because their optimizer doesn't do the optimizations that would make
> the
> bounds checking faster.
> 
> Chris
> 
> 
> 
> On 10/27/08 5:08 PM, "James Burgess" <address@hidden> wrote:
> 
>> They have consistently maintained that the performance hit is minimal
>> except for "unusual cases" what ever that means. If you look through
>> the msdn forums you'll see that the engineers involved are always very
>> interested in specific test cases that perform poorly which they do
>> admit exist. If you have one I would suggest you post it there.
>> 
>> I'm curious, do you have timings to illustrate your frustration?
>> 
>> The debug mode iterator checks do have a significant performance
>> overheard but I think everyone would agree that's ok.
>> 
>> 
>> 
>> 
>> 
>> On Oct 27, 2008, at 4:50 PM, Borislav Trifonov wrote:
>> 
>>> I set it to 0 across all my libraries and it's all good now.  How
>>> Microsoft can have this checking enabled in Release build by default
>>> is beyond me...
>>> 
>>> 
>>> 
>>> ----- Original Message -----
>>> From: Chris Cox <address@hidden>
>>> Date: Monday, October 27, 2008 2:09 pm
>>> Subject: Re: [Openexr-devel] Pulling my hair out: switching
>>> projecttoVS2008breaks OpenEXR :(
>>> To: address@hidden
>>> 
>>>> You have to specify _SECURE_SCL=0 in every module of your
>>>> project, including
>>>> static and dynamic libraries.   Otherwise the vector
>>>> data structure changes
>>>> size and the module with the larger size will barf on memory.
>>>> 
>>>> You can thank Microsoft for the fragile implementation and the
>>>> huge slowdown
>>>> if you fail to set it to zero.  (some of our applications
>>>> need it set to
>>>> zero even for debug builds, because the added overhead is very,
>>>> very high)
>>>> 
>>>> Chris
>>>> 
>>>> 
>>>> 
>>>> On 10/24/08 10:04 PM, "Bob Friesenhahn"
>>>> <address@hidden>wrote:
>>>> 
>>>>> On Sat, 25 Oct 2008, address@hidden wrote:
>>>>> 
>>>>>> It turns out that having _SECURE_SCL=0 defined in my project
>>>> (not even in the
>>>>>> OpenEXR project) is what OpenEXR couldn't handle--for
>>>> whatever reason I
>>>>>> cannot imagine. What's going on here? I need this setting as
>>>> otherwise the
>>>>>> slowdown from the bounds checking the Visual Studio nanny
>>>> does on STL vectors
>>>>>> in opposition to the standard is unacceptable.
>>>>> 
>>>>> Google says:
>>>>> 
>>>>> 
>>>> 
> http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Fee
> dbac
>>>> kI 
>>>> D=352481
>>>>> 
>>>>> "Specifing a project with #define SECURE_SCL 0 which uses
>>>>> std::vector<..> may result into a case in which the application
>>>>> overwrites memory."
>>>>> 
>>>>> Bob
>>>>> ======================================
>>>>> Bob Friesenhahn
>>>>> address@hidden,
>>>> http://www.simplesystems.org/users/bfriesen/> GraphicsMagick
>>>> Maintainer,    http://www.GraphicsMagick.org/
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Openexr-devel mailing list
>>>>> address@hidden
>>>>> http://lists.nongnu.org/mailman/listinfo/openexr-devel
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Openexr-devel mailing list
>>>> address@hidden
>>>> http://lists.nongnu.org/mailman/listinfo/openexr-devel
>>>> _______________________________________________
>>> Openexr-devel mailing list
>>> address@hidden
>>> http://lists.nongnu.org/mailman/listinfo/openexr-devel
>> 
>> 
>> 
>> _______________________________________________
>> Openexr-devel mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/openexr-devel
> 
> 
> 
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
>