In late May 2004, Microsoft made the announcement that it was considering entering the High-Performance Computing (HPC) Market, a market that has traditionally been dominated by custom-engineered Unix-based machines. In recent years, advances in technology have made possible the construction of lower-cost computing clusters that utilize off-the-shelf hardware such as Intel- and AMD-based processors. The operating system of choice for these lower-end clusters has been Linux. In fact, this market is representative of one of Linux's strongest footholds. Many in the Linux camp consider this move as little more than an attempt to strike out against the open source operating system. Competitive motives aside, the idea of a Windows-based supercomputer is not without merit.

Without question, more and more businesses and individuals have come to depend on computers for the analysis of data, and, as time goes on, these businesses and users want the ability to work with larger and larger data sets and perform increasingly complex analyses. The uses of HPC are no longer limited to avenues of science and engineering research. This growing demand is part of what is fueling the development of low-cost computing clusters. While Linux is readily adaptable and highly suited for such tasks, Windows has the benefit of familiarity to most computer users. Windows Server HPC Edition would be a major step in putting more powerful data analysis resources into the hand of the average user. Perhaps this greater analytical power could even be encapsulated in commonly-used applications such as Excel or SQL Server, making the use of certain high-performance computing processes seamless.

While the concept of familiarity is a great advantage for the end user, for Windows developers, writing code for a high-performance computing platform will present some unique challenges.

Parallel Processes
The first challenge is that high-performance computing applications generally run in a parallelized environment because they are generally large-scale simulations that require long times to compute or need to work with high volumes of input data in real-time. The parallelized architecture helps to improve application performance and speed, and ensures that the computation can be completed in a reasonable period of time.

To facilitate the use of these parallel processors, applications need to be divided up into multiple processes that utilize their own memory. However, the division of a program into a series of processes alone is far from sufficient. You can easily imagine that one process might be dependent upon the output of another, or that information may need to be shared between processes.

The processes that comprise an application need to be developed in a way that will allow them to operate in a coordinated and cooperative manner. Traditionally, this has been approached through a technique known as message passing. In this context, a message acts as a medium that allows one process to send information to another process. The principle behind it is that each process has its own memory and therefore its own address space. Message passing will send a piece of data from one address space and allow for it to be received by a second address space. This process is often facilitated through the use of tags, which allow the receiving process to identify messages and the types of content they may hold. Currently, one of the most popular methods of accomplishing this is to use the Message Passing Interface (MPI) Standard. MPI is a library specification that serves as a message-passing model. For an HPC version of Windows to succeed, support for an MPI-type library would need to be incorporated into Windows and developers considering writing HPC Windows' applications would need to learn how to utilize such a library to parallelize their code.

Shift Away from the Desktop
The other significant challenge to developers is that programmers who work in the Windows environment are generally familiar with programming desktop-centric applications, as is readily exemplified by the success of the Visual Basic and Visual C# programming platforms. High-performance computing initiatives, however, are much less desktop-centric and are usually designed to be controlled remotely. In fact, remote administration is an essential component for the clustered environment found in the high-performance computing world, since resources must be shared by all computers that comprise or are connected to the cluster. The use of distributed resources is not a new concept to .NET and a .NET framework does currently exist for utilizing remote resources in applications (i.e., .NET Remoting). However, a transition to HPC-based architectures will make the ability to control remote resources through program code an even more valuable skill. .NET remoting is a process for allowing inter-application communication to occur, even if the applications are found on different computers or networks. It is conceptually similar to Web services, with the difference being that Web services only allow for communication over HTTP and information must be exchanged via XML. Remoting can occur over any type of protocol and is not limited to XML. The downside to remoting is that it requires that all clients are built upon the same remoting framework, so it does not support the high level of interoperability that Web services offer.

Furthermore, despite the speed of HPC machines, it may still take a significant amount of time for finalized results to appear for many jobs. As a result, it is not uncommon in the HPC world for processes to be shifted to the background. This is something that programmers must consider as well, because most Windows developers are familiar with authoring applications that are designed to run as active foreground processes that have direct and continuous user interaction. In the Unix/Linux world, long-running background calculations are generally initiated at the command line. However, this type of approach would eliminate the ease-of-use benefits associated with Windows. A feature that would be key to the success of a high-performance Windows platform would be the ability to set up long-running processes with visual interfaces, using check boxes, radio buttons, and the like to specify parameters, rather than demanding the memorization of long lists of command switches and flags. Once you have properly specified the required parameters and have begun execution of the process, the GUI can close and the process switches from the foreground to the background. This type of approach would free up desktop space and system resources while the processes undergo lengthy executions. For high-performance computing applications, it would be a great benefit if the GUI and the program logic were not explicitly linked. In other words, the application execution should not depend on the presence of an open GUI window, as many typical Windows applications do.

The larger-scale use of remote and background processes by HPC clusters will require a paradigm shift in the way certain Windows HPC applications are coded. Hopefully, features that more readily allow the development of such applications will be incorporated in future versions of Visual Studio. In fact, such updates to the .NET framework and Visual Studio will likely be essential to the success of Windows HPC, because the choice for using a given OS is somewhat driven by the applications that are available to run on it.

Conclusion
All in all, despite the fact that Windows developers may have to adopt some different programming practices to effectively create HPC applications, the potential offered by HPC should make the endeavor worthwhile. An HPC edition of Windows will not only allow Windows developers to dream of coding applications of a magnitude that might not be feasible on today's Windows machines, but will also make those applications more widely accessible to someone with the skill set of the average computer user. The only real challenge to such a platform is whether or not it can gain acceptance in a field that has been dominated by *nix operating systems for decades. For that, only time will tell.