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

Mike Jackson mike.jackson at imts.us
Fri Aug 22 13:08:39 EDT 2008


On Aug 20, 2008, at 5:53 PM, Mike Jackson wrote:

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


Just a quick test to see what performance _might_ be available. I  
wrote a quick program to load a large (980K) Header file into memory  
and look for all instances of "IPPAPI" within that file. Timing just  
the loop to do the search yielded a time of 1~3 milliseconds on a  
2.16 GHz Core Duo MacBook Pro. Using the STL instead in a loop yield  
a time of 8~10 milliseconds.

If anyone want to see the code I can post it here or somewhere else.  
This just tests the "Find" function which is one of many but I think  
the basic theory holds that there _could_ be a large performance  
boost if these libraries were to be used. I'll keep hacking away at  
it and see what happens.


Mike






More information about the CMake mailing list