[Insight-developers] itkVector, itkPoint and vnl_vector

[Miller, James V (CRD)]

I agree that the way to fix this is to work with the vnl folks to change vnl_vector_fixed. That way
we maintain an ability to use vectors and points in matrix computations.  I'd hate to have to have
our own implementations of vector and point and maintain the ability to multiply by vnl matrices,
etc.

In the interim, I don't think the 8 byte overhead is a big deal (for now).  I suggest we proceed with
converting itk::Point to using vnl_vector_fixed and keep pushing on the vnl folks to redesign
vnl_vector_fixed.

For those interested in where the overhead of vnl_vector_fixed comes from:

vnl_vector_fixed stores is data in a standard array T[n]. There is no additional overhead for this.
However, vnl_vector_fixed is a subclass of vnl_vector which normally has it length set at
construction time.  So, vnl_vector stores a pointer and a length and normally allocates memory at
construction time.  vnl_vector_fixed uses a "back-door" constructor, avoiding the memory allocation
of vnl_vector but assigning the pointer and length of the vnl_vector with the address and length of
the standard array of vnl_vector_fixed.  All the matrix operations are implemented using the
vnl_vector API.  So the 8 byte overhead in vnl_vector_fixed is from the pointer and length ivars of
vnl_vector.

Bottom line is that the vnl folks should be able to redesign the vnl_vector hierarchy.  One
possibility is have vnl_vector contain no data at all and two separate subclasses vnl_vector_dynamic
and vnl_vector_fixed.



-----Original Message-----
From: Will Schroeder [mailto:will.schroeder@kitware.com]
Sent: Thursday, January 04, 2001 7:02 AM
To: luis.ibanez@ieee.org; insight-developers@public.kitware.com; Miller,
James V (CRD)
Subject: Re: [Insight-developers] itkVector, itkPoint and vnl_vector


Hi Folks-

Several other people have expressed concern regarding the 8-byte overhead 
of the
itkPoint/itkVector using vnl_vector_fixed. (Remember, this is 8-bytes out 
of 12-bytes
that a 3D float point would be required to have, a 67% overhead!)

I'm more convinced that this is a real problem. Bill Hoffman is 
communicating with the
vnl people to see about reworking vnl_vector_fixed, because quite frankly 
its overhead
IMHO seems to be a design problem (its inheritance introduces the problem).

Maybe we can spend a little time on Friday talking about this.

Will

At 03:43 PM 1/3/2001 -0500, Luis Ibanez wrote:
>Will Schroeder wrote:
>
> > Hi Jim-
> >
> > In that case I would argue that itkVector should not
> > be implemented with vnl_vector :-) I think memory issues
> > are very important. My experience with big data sets
> > is that the difference between choosing one package over
> > another often boils down to its performance when the data
> > is large, which is usually a function of memory as the
> > system strains to swap, etc.
> >
> > Will
>
>Given that a lot of this will be used only in 2D and 3D
>maybe it could be worth to specialize a set of (Vector,
>Point, AffineTransformation) for 2D/3D without using
>vnl_vector's (to respect the memory constrains), and keep
>a generic set (Vector,Point AffineTransform) for N-D
>using the vnl_vector.
>
>
>The extra bytes that vnl_vector costs will be less
>significant in higher dimensions, and it is in those
>higher dimensions that we don't want to do matrix
>multiplications 'by hand'.
>
>
>If the same API is maintained for both sets, that
>could be a balance between speed, memory usage
>and code reuse.
>
>
>Luis
>
>_______________________________________________
>Insight-developers mailing list
>Insight-developers@public.kitware.com
>http://public.kitware.com/mailman/listinfo/insight-developers


_______________________________________________
Insight-developers mailing list
Insight-developers@public.kitware.com
http://public.kitware.com/mailman/listinfo/insight-developers