[Insight-developers] Template Meta Programming and itkImageBase

[Bill Lorensen]

Unfortunately, it seem that changing the default to ON does not change
the value in the cache. I think a clean cache is required.

Bill

On Sun, Oct 19, 2008 at 10:39 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Performance tests I did a while ago:
> http://www.itk.org/Wiki/Proposals:Orientation#Recursive_Templates_for_fast_computation_of_Index-Point_transform
>  show a large difference between the use of recursive templates and
> compiler optimized code.
>
> I'll try top resurrect these tests.
>
> Bill
>
> On Sun, Oct 19, 2008 at 10:03 AM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>>
>> Bill,
>>
>>
>>      Agree,
>>      this was mostly a documentation issue.
>>
>>
>> The previous implementation of the code had the expression:
>>
>>
>>   #if 1
>>        // template meta-programming implementation here
>>   #else
>>        // standard for loops implementation here
>>   #endif
>>
>>
>> which obviously was intended to be used temporarily for local debugging,
>> but that unfortunately remained with the code...   for way too long.
>>
>>
>> The consequence is that the "else" portion has not been tested recently,
>> and therefore, it is broken, as probably illustrated by:
>>
>> http://www.cdash.org/CDash/testSummary.php?project=2&name=itkOrientedImage2DTest01&date=2008-10-19
>>
>>
>> In addition, the "1" in the #if doesn't provide any indication
>> of what the "if" is about. Which is an unfortunate lack of
>> documentation for future maintenance of the code.
>>
>>
>> Recent tests on gcc with -O3 illustrated that the compiler is
>> actually able to unroll the for-loops and that the code with
>> template meta-programming wasn't necessarily faster.
>>
>>
>> By reconnecting this options to a CMake flag we can now:
>>
>>
>>   1) Make sure that the "else" can be easily tested,
>>      (maybe nightly, at least in some machines)
>>
>>   2) Re-evaluate the performance comparison of both
>>      implementations.
>>
>>
>>
>> Your point of backward compatibility is well taken,
>> therefore I'm turning the CMake flag:
>>
>>   ITK_USE_TEMPLATE_META_PROGRAMMING_LOOP_UNROLLING
>>
>> to be ON by default.
>>
>> http://www.itk.org/cgi-bin/viewcvs.cgi/CMakeLists.txt?root=Insight&view=log
>> http://www.itk.org/cgi-bin/viewcvs.cgi/CMakeLists.txt?root=Insight&r1=1.318&r2=1.319
>>
>>
>> This should bring the code back to behave just as when
>> the  "#if 1"   was in place.
>>
>>
>> We can now use the following Nightly tests:
>>
>>   itkOrientedImageProfileTest1.cxx
>>   itkOrientedImageProfileTest2.cxx
>>   itkOrientedImageProfileTest3.cxx
>>
>> to verify the computation time performance of the methods:
>>
>>   TransformIndexToPhysicalPoint()
>>   TransformPhysicalPointToIndex(_
>>
>> in the
>>
>>   a) itk::OrientedImage  (test 1)
>>   b) itk::Image          (test 2)
>>   c) itk::VectorImage    (test 3)
>>
>>
>> After running these profiling tests in multiple platforms
>> we will be in a better informed position to decide whether
>> we want to keep the option, or simply stick to one of the
>> two implementations and remove the alternative code.
>>
>>
>> My suggestion will be to base our test only on builds
>> that use "Release" compilation mode, although one could
>> argue that it may be desirable to have an option that could
>> make Debug builds run faster...
>>
>>
>> Thanks for any suggestions,
>>
>>
>>     Luis
>>
>>
>> ---------------------
>> Bill Lorensen wrote:
>>>
>>> Luis,
>>>
>>> I noticed that the image helper methods are now enclosed within the
>>> ITK_USE_TEMPLATE_META_PROGRAMMING_LOOP_UNROLLING  #ifdef. I suggest
>>> that we do away with this cmake option. The image helper methods have
>>> been the default behavior for oriented imaged from the beginning. I
>>> see no reason to make that code optional now that we're also using it
>>> in itkImage.
>>>
>>> Bill
>>>
>>
>