[mvapich-discuss] (no subject)

Mon Sep 29 12:19:48 EDT 2008

Glad to hear the release of MVAPICH 1.1RC1. 
  I want to known which platform this version can runs on, including  X86, IA64 or somewhat? Does It require some special version of OFED, OS kernel or not?

  Because I have some  trouble on IA64 cluster produced by HP. My applications always happened segments fault , I use mvapich-1.0(2/28/2008) for MPI, and  configure it with default make.mvapich.gen2.

mvapich-discuss-request at cse.ohio-state.edu Ð´µÀ£º
  Send mvapich-discuss mailing list submissions to
mvapich-discuss at cse.ohio-state.edu

To subscribe or unsubscribe via the World Wide Web, visit
http://mail.cse.ohio-state.edu/mailman/listinfo/mvapich-discuss
or, via email, send a message with subject or body 'help' to
mvapich-discuss-request at cse.ohio-state.edu

You can reach the person managing the list at
mvapich-discuss-owner at cse.ohio-state.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of mvapich-discuss digest..."

Today's Topics:

1. Announcing the release of MVAPICH 1.1RC1 (Dhabaleswar Panda)
2. Bug in Allreduce for user-defined ops (Jack Poulson)

----------------------------------------------------------------------

Message: 1
Date: Sun, 28 Sep 2008 00:37:59 -0400 (EDT)
From: Dhabaleswar Panda 

Subject: [mvapich-discuss] Announcing the release of MVAPICH 1.1RC1
To: mvapich-discuss at cse.ohio-state.edu
Cc: Dhabaleswar Panda 

Message-ID:

Content-Type: TEXT/PLAIN; charset=US-ASCII

The MVAPICH team is pleased to announce the release of MVAPICH 1.1RC1 with
the following NEW features:

- New Features for OpenFabrics Gen2-IB Interface
- eXtended Reliable Connection (XRC) support
- Lock-free design to provide support for asynchronous
progress at both sender and receiver to overlap
computation and communication

- New OpenFabrics Gen2-Hybrid interface
- Replaces the Gen2-UD interface of MVAPICH 1.0 series
- Targeted for large-scale IB clusters (multi-thousand cores) to
provide highest performance and minimal memory usage
- Support for UD, RC and XRC transports
- Adaptive selection during run-time (based on application and
systems characteristics) to switch between RC and UD
(or between XRC and UD) transports
- Delivers performance and scalability with near constant
memory footprint for communication contexts
- Zero-copy protocol with UD for large data transfer
- Multiple buffer organizations with XRC support
- Shared memory communication between cores within a node
- Multi-core optimized collectives
(MPI_Bcast, MPI_Barrier, MPI_Reduce and MPI_Allreduce)
- Enhanced MPI_Allgather collective

For downloading MVAPICH 1.1RC1, associated user guide and accessing
the SVN, please visit the following URL:

http://mvapich.cse.ohio-state.edu

This version is also being made available through OFED 1.4.

All feedbacks, including bug reports and hints for performance tuning,
patches and enhancements are welcome. Please post it to the
mvapich-discuss mailing list.

Thanks,

The MVAPICH Team

------------------------------

Message: 2
Date: Sun, 28 Sep 2008 00:13:42 -0500
From: "Jack Poulson" 

Subject: [mvapich-discuss] Bug in Allreduce for user-defined ops
To: mvapich-discuss at cse.ohio-state.edu
Cc: Robert van de Geijn 
Message-ID:
<1ef1de420809272213i45d98b62oa90bf05d15594e34 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

I believe I've run into a bug in the implementation of Allreduce for
user-defined functions in MVAPICH 1.0 and 1.0.1 (0.9.8 works).

In 0.9.8, for power-of-two processes, the user-op is called log2 times
with the correct length. In the new versions, it appears to be called
log2+2 times, where the first call to the user-op passes in a count of
zero (I found this by simply printing it from within the user-op).
I've looked through the intra_Allreduce routine in
src/coll/intra_fns_new.c, but I don't see why the user-op is called
more than log2 times for power-of-two processes.

Should user-defined ops check to ensure the length is nonzero? I've
attached a driver and output that demonstrate the problem. The issue
causes problems in operations such as a custom pivoting operation in
an LU factorization, where an integer is tacked onto the end of a set
of doubles, and a zero length in bytes would cause the routine to
decide negative doubles are being operated on. I've been working
around the problem with a custom Allreduce implementation that uses a
reduce-to-one/bcast, but I would like to take advantage of your team's
multicore optimizations.

Thank you,
Jack Poulson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: user_op.c
Type: text/x-csrc
Size: 1938 bytes
Desc: not available
Url : http://mail.cse.ohio-state.edu/pipermail/mvapich-discuss/attachments/20080928/2878e0d7/user_op.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: user-op-0.9.8
Type: application/octet-stream
Size: 23200 bytes
Desc: not available
Url : http://mail.cse.ohio-state.edu/pipermail/mvapich-discuss/attachments/20080928/2878e0d7/user-op-0.9.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: user-op-1.0
Type: application/octet-stream
Size: 2709 bytes
Desc: not available
Url : http://mail.cse.ohio-state.edu/pipermail/mvapich-discuss/attachments/20080928/2878e0d7/user-op-1.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: user-op-1.0.1
Type: application/octet-stream
Size: 2692 bytes
Desc: not available
Url : http://mail.cse.ohio-state.edu/pipermail/mvapich-discuss/attachments/20080928/2878e0d7/user-op-1.0.obj

------------------------------

_______________________________________________
mvapich-discuss mailing list
mvapich-discuss at cse.ohio-state.edu
http://mail.cse.ohio-state.edu/mailman/listinfo/mvapich-discuss

End of mvapich-discuss Digest, Vol 33, Issue 14
***********************************************

---------------------------------
 ÑÅ»¢ÓÊÏä£¬ÄúµÄÖÕÉúÓÊÏä£¡
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.cse.ohio-state.edu/pipermail/mvapich-discuss/attachments/20080929/a3fd48da/attachment.html