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

Mike Jackson mike.jackson at imts.us
Wed Aug 20 17:53:59 EDT 2008


--  
Mike Jackson   Senior Research Engineer
Innovative Management & Technology Services


On Aug 20, 2008, at 5:17 PM, Alexander Neundorf wrote:

> 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.

We don't know until we profile but since the IPP functions are both  
optimized for SSE and threaded I would assume a reasonable speed up  
in some operations. But we don't know until I try some profiling.

>
>> 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.

Well, if it speeds things up significantly then maybe those that want  
to put out "optimized" versions for various platforms can. Dunno. I  
just don't want to have to maintain a bunch of patches. I would  
rather have it incorporated into the CMake codebase and turned on if  
wanted.

>
>> 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
>

All the IPP string functions take a char* and length as their  
arguments so the IPP functions may be able to "slip right in" without  
a lot of work.

I think I'll run some profiling, grab some of the low hanging fruit,  
and then test side by side a normal version and an IPP optimized  
version.

Thanks for the feedback
Mike Jackson




More information about the CMake mailing list