|The Leading Source for Global News and Information Covering the Ecosystem of High Productivity Computing / September 28, 2007|
Historically, compute clusters have emerged as a less expensive, more practical option for harnessing high performance computing power using systems that were already available in-house. In highly technical settings, such as academia and national laboratories, many researchers and IT managers could not afford to purchase supercomputers so they networked systems together to creatively solve complex computational problems.
The original Beowulf cluster built at NASA in the late 1990s is the epitome of this paradigm shift. Over the last decade, with the evolution of programming standards, refinements in packaging, and improvements in interconnect technology, compute clusters are becoming increasingly attractive to commercial companies. Commercial organizations are choosing cluster environments, not just for financial reasons, but also for their computational scalability. When companies need more power and reach, they simply add another server to their cluster. As a result, clusters have become more appealing to certain high-growth commercial sectors, such as financial services, as a viable alternative for high performance computing.
While there are many companies interested in taking advantage of clusters, many have not yet made the leap. One of the primary reasons for not moving to a cluster environment is that many of these organizations have legacy applications that run well on a traditional server. The cost to migrate the application to a cluster is too high. To further complicate the situation, the application may be a mission-critical asset and to attempt to migrate it to a new system is considered too risky.
Many programs that continue to run on VMS-based platforms fall into this category. The system is reliable and the application executes properly. So despite being considered by many as outdated technology, the organization relying on the VMS-based program would have no short-term migration plan.
However, there are factors driving change. From a performance perspective, compute clusters are becoming more powerful, so organizations are sacrificing performance by staying with outdated platforms. From a personnel perspective, keeping applications on older platforms is becoming riskier, as there are fewer and fewer trained experts in these older technology areas.
When applications are initially developed, there are steps that can be taken to make a future migration less painful and risky. For existing applications that require migration or porting, such as ones being moved to a cluster environment, there are a number of potential porting issues to address along the way. The following provides a brief overview of those issues and how companies can avoid them before they get started.
Preserving Computational Accuracy While Porting Proprietary Applications
While using standard software solutions in a compute cluster helps companies ensure application compatibility with minimum conversion issues, the truth is that many companies have a number of custom, proprietary applications that need to be ported. When porting proprietary applications, the real challenge is to ensure that computational accuracy stays intact when the process is complete.
One of the most reliable sources of computational integrity is commercial numerical libraries. Commercial libraries utilize the numerical representation of the architecture for computational consistency. For example, the convergence criteria for a nonlinear least squares optimization algorithm may be based on a system-specific parameter, such as the largest relative floating point spacing versus a hard-coded value. The hard-coded value may work fine on the original development system, but when porting that algorithm to a system with a different floating point representation, there is a high likelihood that the algorithm will not perform as expected. Relying on the commercial version of the algorithm will avoid these potential problems and significantly reduce the amount of debugging time needed when porting applications to a new environment.
If proprietary applications are already developed, companies can retrofit them with commercial libraries before porting to a new platform. If the proprietary application is "home-grown," an organization may consider substituting algorithms from a commercial library for algorithms that were developed in-house or obtained as open source. There are a variety of reasons why the home-grown application may not perform reliably on a new platform. The algorithm from a commercial library is designed to execute consistently across all supported platforms.
Optimizing Performance and Scalability without Sacrificing Portability
Hardware vendors offer companies more alternatives than ever before for setting up cluster environments. Besides the hardware, they also recommend applicable software as well as services. The hardware vendors have spent considerable effort to help customers optimize applications on their particular platform. These efforts by vendors to optimize the performance on the supported platform are truly a result of the evolution of high performance computing itself.
In its early days, the mechanisms to make high performance computing work were in the public domain. A good example is the Message Passing Interface (MPI), the defacto standard for many years for communication between processes in a compute cluster environment. As MPI has evolved, the major hardware vendors with compute cluster offerings have developed optimized message passing interfaces for their own platforms.
While it's recommended to use these vendor optimized mechanisms for high performance applications, it will add complexity. When porting applications between hardware platforms, if the algorithms used in application development are home grown, they need to be thoroughly tested to ensure they perform reliably. Again, using algorithms from a commercial library designed to execute consistently across multiple supported platforms can reduce porting risks.
Porting Proprietary Applications in Different Languages
Porting can be problematic if an organization has developed applications in a variety of different languages such as Fortran, C or Java. Porting programs of this nature to a new environment introduces more obstacles than porting a single language program. Generally, an organization that has multiple language programs is intent on standardizing on one particular language and converting as many of the programs as possible to that language.
However, dealing with multiple porting components, a platform migration, a performance impact, and a language migration can quickly become very complex. As stated above, utilizing commercial libraries can ease this transition significantly. Some commercial libraries offer the same computational algorithms in multiple languages.
Therefore if a company has a program that utilizes an interpolation function from a library in a Fortran application and they choose to migrate to C, then they may reference the C version of that function without compromising the accuracy of the calculation. When factoring in a cluster environment in this scenario, the application performance also comes into question. Will the language-converted application perform well on the new system?
Again, third party technology should help in this area. If the application was written in-house or uses embedded public domain software, all of that code would need to be rewritten in the new language and optimized for performance. By relying on optimized versions of software from a vendor, the amount of recoding will be reduced and leveraging the performance of the new system may be automatic.
Libraries Are Gaining More Power in Parallel Processing
As compute clusters become more prevalent and powerful, computational libraries continue to evolve to assist the developer in leveraging the cluster technology. Building parallel processing-enabled applications can be difficult, and commercial libraries can help programmers avoid some of the issues associated with optimizing code for a cluster. In fact, some libraries have introduced techniques that assist not only the sophisticated programmer but also the novice distributed computing developer. Examples of such features include:
In addition to the capabilities and techniques described above, another benefit of commercial libraries is simply risk reduction. The commercial library vendor will grow the capabilities of their library while continuing to address the computational accuracy, portability and language issues discussed earlier in this article.
Considerations for Clustering
To recap, before organizations take advantage of a compute cluster, they need to consider what kind of proprietary applications they already have, and what level of developer expertise exists to properly recompile, test, debug, and possibly convert to a new language before porting them to cluster systems.
Companies should also choose native libraries that can operate with a range of computing environments to avoid the pitfalls of porting, while still taking advantage of all the benefits of cluster systems. Knowing some of these pitfalls and complexities of porting to cluster systems will, in the long run, help companies save time and money.
About the Author
Tim Leite is the Director of Corporate Development and Educational Programs for Visual Numerics, Inc. Tim is responsible for many of the product related corporate partnerships. In his education role, he is responsible for establishing partnerships with academic institutions and facilitating the computational requirements of researchers and instructors within the academic community.
Tim has been with Visual Numerics for 21 years in various roles. He started as a mathematical programmer working with algorithms in the areas of linear algebra, transforms, nonlinear systems of equations, and numerical optimization. He was also responsible for optimizing algorithm performance for high performance computing systems. Other roles at Visual Numerics included Technical Support Manager, Product Manager, and Software Development Director.