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