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
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
