[CMake] Using Intel Integrated Performance Primitives (IPP) in CMake

[Alexander Neundorf]

On Wednesday 20 August 2008, Mike Jackson wrote:
> Just a slow day while we wrap some things up and I was looking
> through the Intel IPP documentation and there are a whole slew of
> optimized string functions that come with the Intel C++ compiler. I
> was wondering a few things about using these within cmake (since
> cmake seems to be parsing lots and lots of strings).
>
> 1) Has anyone tried out the IPP string functions to see if they
> really do generate faster code

Using the IPP functions to decode/encode JPEGs on XScale processors brought a 
really big improvement compared to plain libjpeg (which is not optimized at 
all for that architecture). I have no idea how much can be gained on a x86 in 
string processing functions. I'd expect less.

> 2) If no one has, what would be a good place to try these functions
> out? I am looking in cmSystemTools at the moment. In other words,
> what would be the "low hanging" fruit to try and optimize with these
> functions (if any more optimization can be done)?
> 3) How much friction would there be to have these as an option in the
> cmake code base? 

I'm not speaking for the core cmake developers, but I would think this may 
require relatively much work/maintainance for relatively few users/little 
advantage.

> For those of us with the Intel C++ Compiler at our disposal?
>
> 4) Is the string parsing really any sort of bottle neck in the first
> place?

You could do some cmake profiling. When I was running cmake with callgrind 
(valgrind), string operations showed up quite at the top. Of course this 
doesn't take I/O into account.
Many/most string functions in CMake take a const char* as argument. In most 
cases this is converted from a std::string (cheap) and also converted back to 
a std::string (should be expensive, strlen + malloc ?).
Converting them/adding variants which take const std::string& as argument may 
have a positive effect.

Alex