Report on Challenges and Resolutions for the Purple Development Environment
Previous AIX development environment experience with ASC White and Early Delivery systems UV and UM was leveraged to provide a smooth and robust transition to the Purple development environment. Still, there were three major changes that initially caused serious problems for Purple users. The first was making 64-bit builds of executables the default instead of 32-bit. The second was requiring all executables to use large page memory. The third was the phase-out of the popular, but now defunct, third-party C++ compiler KCC, which required the migration of many codes to IBM's xlC C++ compiler. On Purple, the default build environment changed from 32-bit builds to 64-bit builds in order to enable executables to use the 4GB per processor (32GB per node) memory available, and in order for the MPI library to do collective optimizations that required the larger 64-bit address space. The 64-bit build environment was made default by setting the IBM environment variable OBJECT{_}MODE to 64 and wrapping third-party software (mainly the gnu compilers) in order to make them handle OBJECT{_}MODE properly. Because not all applications could port to 64-bit right away, (usually due to third-party constraints, such as python not supporting 64-bit AIX builds until very recently), 32-bit builds of the major common third-party libraries also had be supported. This combined 32/64 bit build support was accomplished fairly seamlessly using the AIX feature that allows both 32-bit and 64-bit versions of the code to appear in the same library file, and documentation with clear examples helped our library developers generate the required combined 32-bit and 64-bit libraries for Purple. In general, the port to 64-bit AIX executables went smoothly. The most common problem encountered with 64-bit was that many C codes didn't prototype malloc everywhere, via ''include <stdlib.h>'', which caused invalid pointers to be returned by unprototyped malloc calls. This was usually seen in old crusty C libraries, leading to segfault on first use of the invalid pointer. Users had not encountered this prototype issue on other 64-bit Operating Systems (Tru64 and SUN) because those vendors worked around this issue by ''auto-prototyping'' malloc for the user. IBM instead required a compiler option to be thrown for autoprototyping. This issue was resolved with user education, and often a quick recognition of the symptoms by support personnel. This addresses a requirement for a report on problems encountered with the tools and environment, and the resolution or status.
- Research Organization:
- Lawrence Livermore National Lab. (LLNL), Livermore, CA (United States)
- Sponsoring Organization:
- USDOE
- DOE Contract Number:
- W-7405-ENG-48
- OSTI ID:
- 896590
- Report Number(s):
- UCRL-TR-226769; TRN: US200703%%844
- Country of Publication:
- United States
- Language:
- English
Similar Records
Developing And Scaling an OpenFOAM Model to Study Turbulent Flow in a HFIR Coolant Channel
Purple L1 Milestone Review Panel TotalView Debugger Functionality and Performance for ASC Purple