This is the second part in a series of articles on the topic: Using the IBM SDK for Linux on Power to improve the performance of a large open source project where I will be using the Migration Advisor. Here we continue exploring the performance of the PHP open source project by looking for the tell-tale signs of missing optimization for the POWER platform in the source.
The Migration Advisor (MA) looks for examples in the code where it uses Intel inline assembler or Intel-specific compiler built-ins. And where this Intel specific code is wrapped in C Pre-Processor (CPP) conditional macro logic and there is no corresponding conditional logic for __powerpc__ or __powerpc64__ specific equivalents.
This is really handy if you are under the pressure to “port” this application or library to the POWER platform or the port “so far” is not performing and you want to find the “low-hanging-watermelons” before doing deep performance analysis. A common problem we see is some low level optimization has been done for Intel but little or none for POWER.
In some cases involving well known patterns that MA recognizes, we can offer a “quick fix”. The IBM SDK offers to edit the specific source code for you by inserting conditional compile logic around the Intel specific code and inserting the equivalent POWER code into the __powerpc64__ leg of the conditional logic.
In the cases where the Intel specific code is not recognized or the conditional logic is too complex for the MA to deal with, MA still is useful. Examples include CPP conditional logic involving multiple else if (#elif) sections or if the conditional logic falls into generic C/C++ code for the default (not Intel) case. This is not to say that MA is not useful for these case, it still finds them and points to exact source files and lines that need work. It just means you will get to use your programmer skills to provides the appropriate fix. So general C/C++ and CPP macro skills are still needed.
It also helps to be familiar with GCC built-in functions including the common cross-platform support, Intel specific, and POWER specific functions. We see these builtin functions a lot in open source codes. You will also see atomic operations in both in-line assembler and using the legacy IA64 style __sync built-ins. Here it is best to convert these to the new C11 Standard atomic operation built-ins.
We are also seeing a lot more use of the vector intrinsic built-ins. These are not provided by the GCC compiler directly but as macros in Intel-specific header files that map the Intel intrinsic to the corresponding GCC built-in. For example; the _mm_add_pd intrinsic maps to the GCC built-in __builtin_ia32_addpd. The MA scans for both spellings and where recognized, will provide a quick fix mapping to the equivalent POWER Vector extension builtin.
Of course both platforms are evolving quickly and each adds new instructions with succeeding generations. This is a moving target and while we strive to keep up, the MA may not have a quick-fixes for the latest intrinsic instructions build-ins. So if you find a case that the MA does not recognize an intrinsic or does not provide a quick-fix, please contact us on the portal. We maintain following table with the mappings we have.
This wraps up the Migration Advisor introduction. I plan to follow-up soon with a series on the Source Code Advisor.