[Insight-developers] CovariantVector::GetSquaredNorm()

[Bradley Lowekamp]

Hello David,

Is the code you use to profile this available?

Little bit of code like this can be very compiler and architecture dependent. There is a lot of potential optimization. Even the way you convert/round the result of the method to the integer your assigning it to can make a big difference, you could look at the round methods in the itk::Math namespace.

Also what architecture and sse instruction sets are you compiling for? x64 arch?

Brad

On Aug 31, 2012, at 4:23 PM, David Doria <daviddoria at gmail.com> wrote:

> The current implementation of CovariantVector::GetSquaredNorm() seems to assume that the component type may have a problem being multiplied and added (overflow). However, when the component type IS capable of these operations, a penalty is still paid in the conversion of everything to double (itk::NumericTraits<every POD>::RealValueType = double).
> 
> In my program, I have images of CovariantVector<int, 3> pixels and I get about a 20% speed up if I change the current implementation:
> 
> template< class T, unsigned int NVectorDimension >
> typename CovariantVector< T, NVectorDimension >::RealValueType
> CovariantVector< T, NVectorDimension >
> ::GetSquaredNorm(void) const
> {
>   RealValueType sum = NumericTraits< RealValueType >::Zero;
> 
>   for ( unsigned int i = 0; i < NVectorDimension; i++ )
>     {
>     const RealValueType value = ( *this )[i];
>     sum += value * value;
>     }
>   return sum;
> }
> 
> to
> 
>  template< class T, unsigned int NVectorDimension >
>  typename CovariantVector< T, NVectorDimension >::ValueType
>  CovariantVector< T, NVectorDimension >
>  ::GetSquaredNorm(void) const
>  {
>    ValueType sum = NumericTraits< ValueType >::Zero;
>  
>    for ( unsigned int i = 0; i < NVectorDimension; i++ )
>      {
>      const ValueType value = ( *this )[i];
>      sum += value * value;
>      }
>    return sum;
>  }
> 
> (note that the return type as well as the internal type has changed).
> 
> I can't think of a reasonable way to determine automatically if there will be a problem (it is not just a signed/unsigned type of problem, but rather it actually depends how large the values are relative to the size of the type). Would it make sense to add a second function called something like GetSquaredNormNoCast() or something like that that can be used in cases where the developer knows that there will be no chance of overflow and would like to get the speed savings?
> 
> Thanks,
> 
> David
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
> 
> 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