[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