[Insight-developers] assert and explicit instantiations
Stephen Aylward
stephen.aylward at kitware.com
Mon Jun 15 17:29:25 EDT 2009
Agreed - that's what led me to thin about loop unrolling.
s
On Mon, Jun 15, 2009 at 3:22 PM, Karthik
Krishnan<karthik.krishnan at kitware.com> wrote:
> I find that odd too..
>
> My understanding was that not single extra cycle would be burned by adding
> exception safety to your code, (unless the exception is actually thrown).
>
> And in that sense exceptions are the best way to build in safety into your
> program; better than (a) Checking return value, since these check the return
> value every time and waste cycles (b) Asserts, since these only in Debug
> mode.
>
>
> On Mon, Jun 15, 2009 at 2:54 PM, Stephen Aylward
> <stephen.aylward at kitware.com> wrote:
>>
>> 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
>> _______________________________________________
>> 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