[Insight-developers] assert and explicit instantiations
Stephen Aylward
stephen.aylward at kitware.com
Mon Jun 15 14:54:20 EDT 2009
Weird!
Somehow loop unrolling is impacted when an exception might be thrown
from within the inner loop?
I'm not certain this would apply to the more complex code of the
iterator as Luis pointed out...but it might...it would be worth a test
for the fuller case...
Stephen
2009/6/15 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>:
>
> Le 15 juin 09 à 18:14, Luis Ibanez a écrit :
>
>>
>> Hi Gaetan,
>>
>>
>> Yes, I see your point.
>> Adding more conditions in the operator++() will degrade performance.
>>
>> Just to clarify here,
>> The penalty in performance will come from the extra "if" that
>> guards that call to the Exception, not from the actual Exception.
>>
>> Exceptions themselves will only be thrown when there is an error,
>> and in that case, performance is no longer an issue. That is, Exceptions
>> will not make part of the normal flow of the code.
>
> I thought like you until I tried to implement the ProjectionImageFilter with
> exceptions to avoid iterating along the full line when the result can be
> know with a few pixels. The results where worth with the try catch code.
>
> The attached progsam does the same number of iterations with and without
> try/catch. Note that no exception is thrown.
> Here are the results I get, with gcc 4.0.1, Release mode:
>
> exception: 1.3971
> if: 0.568379
>
> The result is very stable - I also tried to run swap the order of the
> measures, without relevant changes.
>
>
>
>
>
>>
>> The effect of the "if" may be not be that significant,
>> given that the current code in the operator++() calls Next()
>> which is a virtual function.
>>
>>
>> Self & operator++()
>> {
>> this->Next();
>> return *this;
>> }
>
> Good point. Virtual functions may have a more important impact than
> try/catch blocks.
>
> Gaëtan
>
>>
>>
>> That said, I fully agree with you in that before taking such
>> route we should profile the impact on performance.
>>
>>
>> Going with pure asserts, as you suggest, seems to be a more
>> reasonable approach.
>>
>>
>> Luis
>>
>>
>>
>> --------------------
>> Gaëtan Lehmann wrote:
>>>
>>> Le 14 juin 09 à 18:43, Luis Ibanez a écrit :
>>>>
>>>>
>>>> Hi Gaetan,
>>>>
>>> Hi Luis,
>>>>
>>>> You should probably use the new Macro:
>>>>
>>>> itkAssertOrThrowMacro
>>>>
>>>>
>>>> That is defined in
>>>>
>>>> Insight/Code/Common/itkMacro.h
>>>>
>>>>
>>>> It will use Asserts when compiled in Debug mode,
>>>> and it will throw Exceptions when compiled in
>>>> Release mode.
>>>
>>> Well, we should carefully use that macro, because exceptions can have
>>> serious impact on performance.
>>> In that case, the assert() is in operator++() and Set() methods of an
>>> iterator.
>>>
>>> http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/Common/itkTreeIteratorBase.h?root=Insight&r1=1.12&r2=1.13&sortby=date
>>>
>>> http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/Common/itkTreeIteratorBase.txx?root=Insight&r1=1.14&r2=1.15&sortby=date This
>>> is the kind of case where I wouldn't replace an assert() by
>>> itkAssertOrThrowMacro(), or at least without carefully measuring the
>>> execution times.
>>> Regards,
>>> Gaëtan
>>>>
>>>>
>>>>
>>>> Luis
>>>>
>>>>
>>>> -----------------------
>>>> Gaëtan Lehmann wrote:
>>>>
>>>>> Hi Julien,
>>>>> I have commented an assert() in
>>>>> Code/Common/itkTreeIteratorBase.h
>>>>> Code/Common/itkTreeIteratorBase.h
>>>>> to fix build with explicit instantiation.
>>>>> The compiler was giving that error:
>>>>> /export/home/glehmann/src/Insight/Code/Common/ itkTreeIteratorBase.h:
>>>>> 182: erreur: ‘assert’ was not declared in this scope
>>>>> Is it the expected behavior?
>>>>> Thans,
>>>>> Gaëtan
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://www.itk.org/mailman/listinfo/insight-developers
>
> --
> Gaëtan Lehmann
> Biologie du Développement et de la Reproduction
> INRA de Jouy-en-Josas (France)
> tel: +33 1 34 65 29 66 fax: 01 34 65 29 09
> http://voxel.jouy.inra.fr http://www.itk.org
> http://www.mandriva.org http://www.bepo.fr
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>
>
--
Stephen R. Aylward, Ph.D.
Director of Medical Imaging
Kitware, Inc. - North Carolina Office
http://www.kitware.com
(518) 371-3971 x300
More information about the Insight-developers
mailing list