Freigeben über

Porting your HPC Code to Windows

  • Artikel

One of the most frequent questions I get when I talk to customers is, what is my best option for porting my Linux HPC code to windows...  As a cross platform developer for the last few years, I had to make sure codes worked on mac/various linux/windows/unix platforms, and it can be a major headache at times.  Fortunately, HPC codes are usually not that difficult to port, as they are often console only (has no gui), and they often use MPI, which is an industrial standard. 

Porting from Unix to Windows often requires a little bit of research first.  There are many options depending on the situation.  I would like to introduce several options and state my personal experiences with these options.

 

1. Cygwin:

Cygwin is a Linux-like environment for Windows. It consists of two parts:

A DLL (cygwin1.dll) which acts as a Linux API emulation layer providing substantial Linux API functionality.

A collection of tools which provide Linux look and feel.

Pros:   Easy port, you can build your Linux apps using the configure script and get it to run with almost no changes to the code.

Cons: Requires the cygwin RUN TIME, and the licensing terms are very unforgiving (GPL). Plus it is only 32 bit!   Remember, you are NOT producing win32 code here, everything must run through the cygwin.dll layer.

I personally would only use it as a Unix environment, but not distribute binaries with Cygwin due to the above restrictions. 

 

2. MingW and MSYS:

Mingw and MSYS: A Minimal system providing a POSIX compatible Bourne shell environment, with a small collection of UNIX command line tools. 

Pros:  POSIX calls, produces win32 code, LGPL licensing, outstanding shell + terminal window.

Cons: 64 bit is in alpha stage, porting usually means more work, since a lot of the linux apis are not posix( it really is minimal). 

I originally ported a lot of code using.  The nice thing is that you can use mingw's gcc to link in an entire application into one windows static binary exe for distribution.  I am not the only one that highly recommend this solution for building windows applications, the folks at trolltech also made it the default compiler environment for their open source edition of QT 4.x.   QT is a cross platform GUI system, that has both open source edition, and a supported commercial version.   My poor man's QT recommendation is Wx Windows, which will work for a lot of people.  The Python Scientific Package I mentioned a couple of months ago uses WxWindows for their TVTK GUI system.  I also liked their terminal window, it was a replacement for windows cmd window until powershell came along.

 

image

 

3. Native Compilers

Intel, Microsoft, PGI, and other commercial companies sell commercial c/c++, fortran compilers on the windows platform.  One of the most popular solution is the Intel compiler suite, since it contains both fortran and c++ compilers.  Almost all of these compilers integrate directly into Microsoft visual studio IDE, which makes life so much easier for developers.

Pros:   Commercial support, IDE integration, better debugging, performance analysis tools, 64 bit support!!

Cons: Requires porting to the win32 API for one, have to establish additional build systems with the IDE based solutions, and those ifdefs for a new compiler!

The good news is that porting HPC apps usually require less effort, as they are usually commandline apps.  Having a different compiler to exercise the source code often exposes flaws you normally don't see using only GCC.  Plus that it is essential to have an IDE to deal with the ever increasing code base of modern scientific code.  It is becoming a trend that a lot of developers prefer Visual studio for productivity. 

 

Conclusion:

Choosing how to port your application depends on your specific needs.  I have presented 3 different ways to port your HPC application, cygwin, mingw, and a native build environment.  I highly recommend the native port approach, as it saves time and effort in the longer run.  I will discuss common porting issues in the next few blogs.

 

Once again, thanks for reading my blog, and I would appreciate any feed backs or questions you may have.

Comments