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