[vtk-developers] Possible changes to vtkMath...

[Chris Volpe]

1) No need to use "fabsf", since I believe that's only there for
C-language compatibility, in which "fabs" can't be overloaded.

2) In an optimized build, fabs is an intrinsic on Intel Architecture
cpus, and will probably generate a single instruction that will run
faster than
the macro. Is there a uniform way to tell at compile time whether we're
compiling in non-optimized mode? E.g.:
#ifdef DEBUG
#define VTK_FABS(x) (((x) < 0.0 ) ? (-(x)) : (x) )
#else
#define VTK_FABS(x) ::fabs(x)
#endif

3) The conditional heap allocation looks like a good idea, but if you
want maximum performance, can you do some conditional compilation on
Win32 to call _alloca()?

-Chris

> -----Original Message-----
> From: Will Schroeder [mailto:will.schroeder at kitware.com]
> Sent: Thursday, July 10, 2003 6:42 PM
> To: vtk-developers at vtk.org
> Subject: [vtk-developers] Possible changes to vtkMath...
> 
> Hi Folks-
> 
> I was profiling VTK and discovered a couple of issues with vtkMath.
The
> fabs() function (used in LUSolve, etc) is taking an surprising amount
of
> time, and I find some leftover static variables. Here's what I'm
> thinking---I'd like your comments.
> 
> fabs()
> We can define a macro #define  VTK_FABS(x)  (x) < 0.0 )?(-(x)):(x))
> Another alternative is to do what vnl does:
> inline float       VTK_FABS(float  x) { return ::fabsf(x); }
> inline double      VTK_FABS(double x) { return ::fabs(x); }
> 
> The macro seems to be a bit faster but I'm running debug not release.
> 
> Static variables will be replaced with code like this that is
partially
> optimized for small matrices:
>  >   int *index, scratch[10];
>  >   index = ( size < 10 ? scratch : new int[size] );
>  >   if (size >= 10 ) delete [] index;
> 
> Comments?
> 
> Will
> 
> 
> 
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at vtk.org
> http://www.vtk.org/mailman/listinfo/vtk-developers