Free mpich software for linux

MPICH2 is a robust and flexible implementation of the MPI (Message Passing Interface). Message Passing Interface is often used with parallel or distributed computing projects.

MPICH2 is a multi-platform, configurable system (development, execution, libraries, etc) for MPI. It can acheive parallelism using networked machines or using mulitasking on a single machine.

GridMPI is a new open-source free-software implementation of the standard MPI (Message Passing Interface) library designed for the Grid. GridMPI project enables unmodified applications to run on cluster computers distributed across the Grid environment.
GridMPI team found that it is feasible to connect cluster computers and to run ordinary scientific applications in distance upto 500 miles. Simple experiment has shown that most MPI benchmarks scale fine upto 20 millisecond round-trip latency which corresponds to about 500 miles in distance, when the clusters are connected by fast 1 to 10 Gbps networks. 500 miles covers the major cities between Tokyo--Osaka in Japan.
Thus, applications which are too large to run on a local cluster should run on multiple clusters in the Grid environment with acceptable performance. However, it is only feasible when using an efficient MPI implementation [1]. Existing implementations are not efficient enough mainly because of the two reasons: their focus on security features and TCP performance problems.
GridMPI skips security layers assuming dedicated secure links. The institutes housing large clusters tend to have their own networks to connect to other institutes in most cases. GridMPI so focuses on the performance on TCP. Since existing implementations are in most cases designed for MPP machines and recently clusters with special hardware, their performance on TCP with Ethernet is not optimal.
Also TCP performance itself is not optimal for the work load of the MPI traffic. In addition, support for heterogeneous combinations of computers of the existing MPI implementations is not satisfactory. Thus, GridMPI is designed and implemented from the scratch. GridMPI is carefully coded and tested with heterogeneity in mind.
Main features:
- Full conformance to the standard: GridMPI passes 100% of the functional tests of the large test suites from ANL and Intel (MPI-1.2 level).
- Full heterogeneity support: GridMPI is fully tested with combinations of processors of 32bit/64bit and big/little-endian.
- Primary support of TCP/IP and sockets: GridMPI is written from scratch and it is new and clean. It is efficient with sockets, and thus suitable for the Grid as well as ordinary Ethernet-based clusters.
- Cooperation with Grid job submission: GridMPI can be used with Globus, Unicore, tool from NAREGI project, etc.
- Checkpointing support: GridMPI supports checkpointing on Linux/IA32 platforms to restart long-running applications from failure.
- Vendor MPI support: GridMPI supports IBM-MPI, Fujitsu-Solaris-MPI, Intel-MPI, and any MPICH-based MPI for clusters with special communication hardware.
Enhancements:
- Minor bugfixes were made.

ParallelKnoppix is a remaster of the Knoppix live CD distibution of GNU Linux that allows setting up a cluster of machines for parallel processing using the LAM-MPI and/or MPICH implementations of MPI.

You can convert a room full of machines running Windows into a Linux cluster, and when you shut down, your Windows machines are in their original state. The computers in the cluster can be homogeneous or heterogeneous.

Getting the cluster up and running takes about 5 minutes, if the machines have PXE network cards. Clusters from 2 to 200 machines are supported.

Parallel Bladeenc is a true parallel version of the Bladeenc MP3 encoder; it distributes work across CPUs to speed up MP3 encoding. It uses the Message Passing Interface (MPI) for parallelization across SMPs and/or multiple machines. Hence, if you have a 4-way SMP, you can encode your MP3s about 4 times as fast as the regular Bladeenc; if you have two 4-way SMPs, you can encode about 8 times as fast.
The difficult part about parallelization is typically about how to split the problem up into independent (or nearly independent) parts. The structure shown above - assuming that the encode() function was independent of previous calls to encode() - is trivial to parallelize.
For example, if we want to run on four machines, we can split the input file into four parts, give 1/4 of the file to each machine, and let each machine loop over encode() for their portion of the file. Then take the output from each machine, put it in the right order, and write it out to a single output file. Done.
With such a scheme, the more work that you throw at it, the more efficient it will become.
Hence, trying this scheme with small MP3 files will probably not result in any noticeable speedup (in fact, it may be slower than running in serial, because of the added overhead for working in parallel). It is necessary to give the parallel engine enough work to offset the overhead added by the parallel framework. Generally, this is not very much overhead (read on to find out why), but parallel is not free.
Enhancements:
- Fixed minor error that caused an error message from MPICH when shutting down. Thanks to Gary Smith for pointing this out.