It's a historical and emotional decision that also used to have a business driver. I learned MPI with LAM on Linux (minute's silence...) and switched to OpenMPI when LAM went to join the big supercomputer in the sky. Shortly after OpenMPI launched, we had some discussions about a Windows version, but it took until 1.5 before there was one because Shiqing did the heavy lifting.

At the time, MS was still heavily into HPC and I used OpenMPI on Windows (and Linux) because I like the team that develops it and wanted to support the product. In 2011 when MS changed the direction of their HPC team I think OpenMPI on Windows lost the actual business driver for a critical mass of users, and that's what we're seeing now. I'll still use OpenMPI on Linux, but I think on Windows it will be HPC Pack or MPICH.

Damien

On 18/12/2012 10:20 AM, JR Cary wrote:
So a question - why do *you* use (native) OpenMPI on Windows, when
you could just download HPC Pack?  Was it for any reason related
to implementation?

(I may have been one of those 2-3 candidate users, but I actually
just download HPC Pack.)

Back to the point of why OpenMPI might be desirable: I agree with
Jeff that it is not about on-node performance, nor use of the network
stack.  It would have to be better or more implementations above that
layer, such as OpenMPI having implementations for some advanced MPI
methods that are absent in HPC Pack (which I understand has forked
from MPICH).

But, yeah, it does seem like the coffin is pretty well shut, otherwise.

Thx...........John

On 12/18/12 9:00 AM, Damien wrote:
Proper Windows support of OpenMPI is likely around 20 hours a week. That can be maintained by a small group, but it's probably too much for one person unless they're working in Windows HPC every day. When I posted a couple of weeks back, there were three people (maybe two?) who responded that they used OpenMPI on Windows regularly, other than me.

I hate to say it, but against MPICH and the Microsoft and Intel MPICH versions with probably a few thousand regular users, I think OpenMPI on native Windows is dead in the water.

Damien

On 18/12/2012 8:06 AM, JR Cary wrote:
On 12/18/12 6:29 AM, Jeff Squyres wrote:
This brings up the point again, however, of Windows support.

Open MPI recently lost its only Windows developer (he moved on to non-HPC things). This has been discussed on the lists a few times (I honestly don't remember if it was this users list or the devel list), and there hasn't really been anyone who volunteered their time to support Open MPI on Windows.

Definitely this list.

We're seriously considering removing all Windows support for 1.7 and beyond (keep in mind that the native Windows support on the SVN trunk and v1.7 branch is very, very out of date and needs some serious work to get working again -- the last working native Windows version is on the v1.6 branch).

Sounds appropriate.  My conversations with Microsoft
went no where.  Spoke last night with another good
friend there who worked in their HPC unit when that
existed.  Microsoft has their own implementation, and
they see no need for another.

So, IMO, OpenMPI would have to turn to a different
group for support.  E.g., Microsoft compatible HPC
application vendors.  And for that one would need a
compelling case of being better in, e.g., performance.

Can this case be made?

Perhaps there is another way?

John






On Dec 18, 2012, at 3:04 AM, Siegmar Gross wrote:

Hi,

I tried to install openmpi-1.9a1r27674 on Cygwin-1.7.17 and
got the following error (gcc-4.5.3).

...
  CC       path.lo
../../../openmpi-1.9a1r27668/opal/util/path.c: In function
  'opal_path_df':
../../../openmpi-1.9a1r27668/opal/util/path.c:578:18: error:
  'buf' undeclared (first use in this function)
../../../openmpi-1.9a1r27668/opal/util/path.c:578:18: note:
  each undeclared identifier is reported only once for each
  function it appears in
Makefile:1669: recipe for target `path.lo' failed
make[3]: *** [path.lo] Error 1
...


The reason is that "buf" is only declared for some operating
systems. I added "defined(__CYGWIN__)" in some places and
was able to compile "path.c".


hermes util 41 diff path.c path.c.orig
452c452
< #elif defined(__linux__) || defined(__CYGWIN__) ||
  defined (__BSD) || (defined(__APPLE__) && defined(__MACH__))
---
#elif defined(__linux__) || defined (__BSD) ||
  (defined(__APPLE__) && defined(__MACH__))
480c480
< #elif defined(__linux__) || defined(__CYGWIN__) ||
  defined (__BSD) || (defined(__APPLE__) && defined(__MACH__))
---
#elif defined(__linux__) || defined (__BSD) ||
  (defined(__APPLE__) && defined(__MACH__))
517c517
< #elif defined(__linux__) || defined(__CYGWIN__)
---
#elif defined(__linux__)
549c549
< #elif defined(__linux__) || defined(__CYGWIN__) ||
  defined (__BSD) || \
---
#elif defined(__linux__) || defined (__BSD) ||            \
562c562
< #elif defined(__linux__) || defined (__CYGWIN__) ||
  defined (__BSD) ||       \
---
#elif defined(__linux__) || defined (__BSD) ||            \
hermes util 42


Searching for "__linux__" delivered some more files which
must possibly be adapted.

opal/config/opal_check_os_flavors.m4
opal/mca/event/libevent2019/libevent/buffer.c


I assume that the following files do not need any changes
because they are special for Linux or for features which
are not important/available for Cygwin.


configure:    { $as_echo "$as_me:${as_lineno-$LINENO}:
  checking __linux__" >&5
configure:$as_echo_n "checking __linux__... " >&6; }
configure:#ifndef __linux__
configure:      error: this isnt __linux__

test/util/opal_path_nfs.c

opal/asm/base/MIPS.asm:#ifdef __linux__
opal/asm/generated/atomic-mips64el.s:#ifdef __linux__
opal/asm/generated/atomic-mips64-linux.s:#ifdef __linux__
opal/asm/generated/atomic-mips-irix.s:#ifdef __linux__
opal/asm/generated/atomic-mips-linux.s:#ifdef __linux__

ompi/mca/common/verbs/common_verbs_basics.c:#if defined(__linux__)
opal/include/opal/sys/cma.h:#ifdef __linux__
opal/mca/memory/linux/arena.c:#ifdef __linux__

ompi/mca/io/romio/romio/configure:        #ifdef __linux__
ompi/mca/io/romio/romio/configure.in:        #ifdef __linux__
opal/include/opal/sys/mips/atomic.h:#ifdef __linux__
opal/include/opal/sys/mips/atomic.h:#ifdef __linux__
opal/include/opal/sys/mips/atomic.h:#ifdef __linux__
opal/mca/event/libevent2019/libevent/arc4random.c:#ifdef __linux__

ompi/mca/io/romio/romio/adio/ad_lustre/ad_lustre.h:#ifdef __linux__
ompi/mca/io/romio/romio/adio/ad_lustre/ad_lustre.h:#endif /* __linux__ */


Can somebody add __Cygwin__ to all necessary files? Now I get
the following error.

...
Making all in mca/if/windows
make[2]: Entering directory
`/home/Admin/openmpi/openmpi-1.9-Cygwin.x86.32_gcc/opal/mca/if/windows'
  CC       opal_if_windows.lo
../../../../../openmpi-1.9a1r27674/opal/mca/if/windows/opal_if_windows.c:
  In function 'if_windows_open':
../../../../../openmpi-1.9a1r27674/opal/mca/if/windows/opal_if_windows.c:58:5:
  error: 'SOCKET' undeclared (first use in this function)
../../../../../openmpi-1.9a1r27674/opal/mca/if/windows/opal_if_windows.c:58:5: note: each undeclared identifier is reported only once for each function
  it appears in
...


Is it necessary to use windows sockets directly or is it possible
to use something similar to Linux sockets? Cygwin supports sockets
(based on Windows sockets as far as I know) and very often uses
similar interfaces as Linux. Which file is responsible for the
selection of "opal_if_windows.c"?

I added the following constants to /usr/include/cygwin/shm.h before
I started to build openmpi-1.9a1r27674.

diff /usr/include/cygwin/shm.h /usr/include/cygwin/shm.h.orig
29,34d28
< /* Permission definitions                   */
< #define SHM_R   0400    /* read permission  */
< #define SHM_W   0200    /* write permission */
<

I used the following commands to configure Open MPI.
"/usr/local/jdk1.7.0" is a link to my Java installation
on Windows 7.

cd /usr/local
ln -s /cygdrive/c/Program\ Files\ \(x86\)/jdk1.7.0 jdk1.7.0


../openmpi-1.9a1r27674/configure --prefix=/usr/local/openmpi-1.9 \
  --with-jdk-bindir=/usr/local/jdk1.7.0/bin \
  --with-jdk-headers=/usr/local/jdk1.7.0/include \
  JAVA_HOME=/usr/local/jdk1.7.0 \
  LDFLAGS="-m32 -Wl,--export-all-symbols -no-undefined" \
  CC="gcc" CXX="g++" FC="gfortran" \
  CFLAGS="-m32" CXXFLAGS="-m32" FCFLAGS="-m32" \
  CPP="cpp" CXXCPP="cpp" \
  CPPFLAGS="" CXXCPPFLAGS="" \
  C_INCL_PATH="" C_INCLUDE_PATH="" CPLUS_INCLUDE_PATH="" \
  OBJC_INCLUDE_PATH="" OPENMPI_HOME="" \
  --enable-cxx-exceptions \
  --enable-mpi-java \
  --enable-heterogeneous \
  --enable-opal-multi-threads \
  --enable-mpi-thread-multiple \
  --with-threads=posix \
  --with-hwloc=internal \
  --without-verbs \
  --without-udapl \
  --without-sctp \
  --with-wrapper-cflags=-m32 \
  --enable-debug \
  --disable-mca-dso \
  --without-cs-fs \
  --enable-contrib-no-build=vt,libompitrace \
--enable-mca-no-build=memory_mallopt,paffinity,installdirs-windows,timer-windows \
  |& tee log.configure.$SYSTEM_ENV.$MACHINE_ENV

It would be great, if I could get a working Open MPI version with
Java interface on Cygwin. Thank you very much for any help in advance.


Kind regards

Siegmar

_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users


_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users

_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users


_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users

Reply via email to