date:20110310

Re: [OMPI devel] turning on progress threads

2011-03-10 Thread Eugene Loh

No big deal one way or the other.  It's a symbolic gesture against bit 
rot, I suppose.  The fact is that there are different pieces of the code 
base that move forward while vestiges of old stuff get left behind 
elsewhere.  At first, it's easier to leave that stuff in.  With time, 
the history gets forgotten and there gets left more and more mysterious 
stuff that future developers have to figure out.


Let's say there's code that doesn't do anything.  One can ask, "Why not 
just leave it in?"  Or, one can ask, "Why not just strip it out?"


This particular case (*.conf enable_progress) is minor.  Either way, 
things are fine.  My concern is more around the accumulation of many 
such instances.


Ralph Castain wrote:


On Mar 10, 2011, at 5:54 PM, Eugene Loh wrote:
 


Ralph Castain wrote:
   


Just stale code that doesn't hurt anything
 


Okay, so it'd be all right to remove those lines.  Right?
   


They are in my platform files - why are they a concern?

Just asking - we don't normally worry about people's platform files. I would 
rather not have to go thru everyone's files and review what they have there.
 


- frankly, I wouldn't look at platform files to try to get a handle on such 
things as they tend to fall out of date unless someone needs to change it.

We always hard-code progress threads to off because the code isn't thread safe 
in key areas involving the event library, for one.

On Mar 10, 2011, at 3:43 PM, Eugene Loh wrote:
 


In the trunk, we hardwire progress threads to be off.  E.g.,

% grep progress configure.ac
# Hardwire all progress threads to be off
enable_progress_threads="no"
  [Hardcode the ORTE progress thread to be off])
  [Hardcode the OMPI progress thread to be off])

So, how do I understand the following?

% grep enable_progress contrib/platform/*/*.conf
contrib/platform/cisco/linux-static.conf:orte_enable_progress_threads = 1
contrib/platform/cisco/macosx-dynamic.conf:orte_enable_progress_threads = 1
contrib/platform/openrcm/debug.conf:orte_enable_progress_threads = 1
% grep enable_progress contrib/platform/*/*/*.conf
contrib/platform/cisco/ebuild/hlfr.conf:orte_enable_progress_threads = 1
contrib/platform/cisco/ebuild/ludd.conf:orte_enable_progress_threads = 1
contrib/platform/cisco/ebuild/native.conf:orte_enable_progress_threads = 1

These seem to try to turn progress threads on.  Ugly, but not a problem?

Re: [OMPI devel] turning on progress threads

2011-03-10 Thread Eugene Loh


Ralph Castain wrote:


Just stale code that doesn't hurt anything


Okay, so it'd be all right to remove those lines.  Right?


- frankly, I wouldn't look at platform files to try to get a handle on such 
things as they tend to fall out of date unless someone needs to change it.

We always hard-code progress threads to off because the code isn't thread safe 
in key areas involving the event library, for one.

On Mar 10, 2011, at 3:43 PM, Eugene Loh wrote:
 


In the trunk, we hardwire progress threads to be off.  E.g.,

% grep progress configure.ac
# Hardwire all progress threads to be off
enable_progress_threads="no"
[Hardcode the ORTE progress thread to be off])
[Hardcode the OMPI progress thread to be off])

So, how do I understand the following?

% grep enable_progress contrib/platform/*/*.conf
contrib/platform/cisco/linux-static.conf:orte_enable_progress_threads = 1
contrib/platform/cisco/macosx-dynamic.conf:orte_enable_progress_threads = 1
contrib/platform/openrcm/debug.conf:orte_enable_progress_threads = 1
% grep enable_progress contrib/platform/*/*/*.conf
contrib/platform/cisco/ebuild/hlfr.conf:orte_enable_progress_threads = 1
contrib/platform/cisco/ebuild/ludd.conf:orte_enable_progress_threads = 1
contrib/platform/cisco/ebuild/native.conf:orte_enable_progress_threads = 1

These seem to try to turn progress threads on.  Ugly, but not a problem?

Re: [OMPI devel] [Fwd: multi-threaded test]

2011-03-10 Thread Ralph Castain

Can't speak to the MPI layer, but you definitely cannot hardwire thread support 
to "off" for ORTE.


On Mar 10, 2011, at 10:57 AM, George Bosilca wrote:

> 
> On Mar 10, 2011, at 11:23 , Eugene Loh wrote:
> 
>> Any comments on this?
> 
> Good luck?
> 
>  george.
> 
> 
>> We wanted to clean up MPI_THREAD_MULTIPLE support in the trunk and port 
>> these changes back to 1.5.x, but it's unclear to me what our expectations 
>> should be about any MPI_THREAD_MULTIPLE test succeeding.  How do we assess 
>> (test) our changes?  Or, should we just hardwire thread support to be off, 
>> as we have done with progress threads?
>> 
>>  Original Message 
>> Subject: [OMPI devel] multi-threaded test
>> Date:Tue, 08 Mar 2011 11:24:20 -0800
>> From:Eugene Loh 
>> To:  Open MPI Developers 
>> 
>> I've been assigned CMR 2728, which is to apply some thread-support 
>> changes to 1.5.x.  The trac ticket has amusing language about "needs 
>> testing".  I'm not sure what that means.  We rather consistently say 
>> that we don't promise anything with regards to true thread support.  We 
>> specifically say certain BTLs are off limits and we say things are 
>> poorly tested and can be expected to break.  Given all that, what does 
>> it mean to test thread support in OMPI?
>> 
>> One option, specifically in the context of this CMR, is to test only 
>> configuration options and so on.  I've done this.
>> 
>> Another possibility is to confirm that simple run-time tests of 
>> multi-threaded message passing succeed.  I'm having trouble with this.
>> 
>> Attached is a simple test.  It passes over sm but fails over TCP.  (One 
>> or both of the initial messages is not received.)
>> 
>> How high should I set my sights on this?
>> 
>> 
>> #include 
>> #include 
>> #include 
>> #include   /* memset */
>> 
>> 
>> #define N 1
>> int main(int argc, char **argv) {
>> int np, me, buf[2][N], provided;
>> 
>> /* init some stuff */
>> MPI_Init_thread(, , MPI_THREAD_MULTIPLE, );
>> MPI_Comm_size(MPI_COMM_WORLD,);
>> MPI_Comm_rank(MPI_COMM_WORLD,);
>> if ( provided < MPI_THREAD_MULTIPLE ) MPI_Abort(MPI_COMM_WORLD,-1);
>> 
>> /* initialize the buffers */
>> memset(buf[0], 0, N * sizeof(int));
>> memset(buf[1], 0, N * sizeof(int));
>> 
>> /* test */
>> #pragma omp parallel num_threads(2)
>> {
>>   int id = omp_get_thread_num();
>>   MPI_Status st;
>>   printf("%d %d in parallel region\n", me, id); fflush(stdout);
>> 
>>   /* pingpong */
>>   if ( me == 0 ) {
>> MPI_Send(buf[id],N,MPI_INT,1,7+id,MPI_COMM_WORLD); printf("%d %d 
>> sent\n",me,id); fflush(stdout);
>> MPI_Recv(buf[id],N,MPI_INT,1,7+id,MPI_COMM_WORLD,); printf("%d %d 
>> recd\n",me,id); fflush(stdout);
>>   } else {
>> MPI_Recv(buf[id],N,MPI_INT,0,7+id,MPI_COMM_WORLD,); printf("%d %d 
>> recd\n",me,id); fflush(stdout);
>> MPI_Send(buf[id],N,MPI_INT,0,7+id,MPI_COMM_WORLD); printf("%d %d 
>> sent\n",me,id); fflush(stdout);
>>   }
>> }
>> 
>> MPI_Finalize();
>> 
>> return 0;
>> }
>> 
>> 
>> #!/bin/csh
>> 
>> mpicc -xopenmp -m64 -O5 main.c
>> 
>> mpirun -np 2 --mca btl self,sm  ./a.out
>> mpirun -np 2 --mca btl self,tcp ./a.out
>> 
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 
> George Bosilca
> Research Assistant Professor
> Innovative Computing Laboratory
> Department of Electrical Engineering and Computer Science
> University of Tennessee, Knoxville
> http://web.eecs.utk.edu/~bosilca/
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

[OMPI devel] turning on progress threads

2011-03-10 Thread Eugene Loh


In the trunk, we hardwire progress threads to be off.  E.g.,

% grep progress configure.ac
# Hardwire all progress threads to be off
enable_progress_threads="no"
  [Hardcode the ORTE progress thread to be off])
  [Hardcode the OMPI progress thread to be off])

So, how do I understand the following?

% grep enable_progress contrib/platform/*/*.conf
contrib/platform/cisco/linux-static.conf:orte_enable_progress_threads = 1
contrib/platform/cisco/macosx-dynamic.conf:orte_enable_progress_threads = 1
contrib/platform/openrcm/debug.conf:orte_enable_progress_threads = 1
% grep enable_progress contrib/platform/*/*/*.conf
contrib/platform/cisco/ebuild/hlfr.conf:orte_enable_progress_threads = 1
contrib/platform/cisco/ebuild/ludd.conf:orte_enable_progress_threads = 1
contrib/platform/cisco/ebuild/native.conf:orte_enable_progress_threads = 1

These seem to try to turn progress threads on.  Ugly, but not a problem?

Re: [OMPI devel] [Fwd: multi-threaded test]

2011-03-10 Thread N.M. Maclaren


On Mar 10 2011, Eugene Loh wrote:


   Any comments on this?  We wanted to clean up MPI_THREAD_MULTIPLE
support in the trunk and port these changes back to 1.5.x, but it's
unclear to me what our expectations should be about any
MPI_THREAD_MULTIPLE test succeeding.  How do we assess (test) our
changes?  Or, should we just hardwire thread support to be off, as we
have done with progress threads?


Please, Please, PLEASE do the latter - at least for MPI_THREAD_SERIALIZED
and MPI_THREAD_MULTIPLE!

There is NO chance that it will ever be reliable and portable while POSIX
threads are in the state they are in.  Even reaching MPI_THREAD_FUNNELED
requires FAR more complexity than most experienced programmers expect.
The Microsoft specifications I have found are no better.  For example,
here are a few issues that I have seen:

Most functions are defined to be 'thread-safe' - which is useless without
a specification of what that means.  To take a simple example, consider
scanf versus ungetc versus lseek 

There are no facilities for synchronising non-memory actions, from I/O
to signals.  POSIX requests read and write to be atomic, but does not
specify it, and it gets extremely hairy to know what that means with a
TCP transfer actually in progress.

Signals are particularly hairy, because I have seen one thread handle
and clear a signal, synchronise with another, which then was told that
the same signal was waiting by sigpending (only to have it disappear
when it was masked back on). 


And so it goes 

Regards,
Nick Maclaren.

Re: [OMPI devel] [Fwd: multi-threaded test]

2011-03-10 Thread George Bosilca


On Mar 10, 2011, at 11:23 , Eugene Loh wrote:

> Any comments on this?

Good luck?

  george.


>  We wanted to clean up MPI_THREAD_MULTIPLE support in the trunk and port 
> these changes back to 1.5.x, but it's unclear to me what our expectations 
> should be about any MPI_THREAD_MULTIPLE test succeeding.  How do we assess 
> (test) our changes?  Or, should we just hardwire thread support to be off, as 
> we have done with progress threads?
> 
>  Original Message 
> Subject:  [OMPI devel] multi-threaded test
> Date: Tue, 08 Mar 2011 11:24:20 -0800
> From: Eugene Loh 
> To:   Open MPI Developers 
> 
> I've been assigned CMR 2728, which is to apply some thread-support 
> changes to 1.5.x.  The trac ticket has amusing language about "needs 
> testing".  I'm not sure what that means.  We rather consistently say 
> that we don't promise anything with regards to true thread support.  We 
> specifically say certain BTLs are off limits and we say things are 
> poorly tested and can be expected to break.  Given all that, what does 
> it mean to test thread support in OMPI?
> 
> One option, specifically in the context of this CMR, is to test only 
> configuration options and so on.  I've done this.
> 
> Another possibility is to confirm that simple run-time tests of 
> multi-threaded message passing succeed.  I'm having trouble with this.
> 
> Attached is a simple test.  It passes over sm but fails over TCP.  (One 
> or both of the initial messages is not received.)
> 
> How high should I set my sights on this?
> 
> 
> #include 
> #include 
> #include 
> #include   /* memset */
> 
> 
> #define N 1
> int main(int argc, char **argv) {
>  int np, me, buf[2][N], provided;
> 
>  /* init some stuff */
>  MPI_Init_thread(, , MPI_THREAD_MULTIPLE, );
>  MPI_Comm_size(MPI_COMM_WORLD,);
>  MPI_Comm_rank(MPI_COMM_WORLD,);
>  if ( provided < MPI_THREAD_MULTIPLE ) MPI_Abort(MPI_COMM_WORLD,-1);
> 
>  /* initialize the buffers */
>  memset(buf[0], 0, N * sizeof(int));
>  memset(buf[1], 0, N * sizeof(int));
> 
>  /* test */
>  #pragma omp parallel num_threads(2)
>  {
>int id = omp_get_thread_num();
>MPI_Status st;
>printf("%d %d in parallel region\n", me, id); fflush(stdout);
> 
>/* pingpong */
>if ( me == 0 ) {
>  MPI_Send(buf[id],N,MPI_INT,1,7+id,MPI_COMM_WORLD); printf("%d %d 
> sent\n",me,id); fflush(stdout);
>  MPI_Recv(buf[id],N,MPI_INT,1,7+id,MPI_COMM_WORLD,); printf("%d %d 
> recd\n",me,id); fflush(stdout);
>} else {
>  MPI_Recv(buf[id],N,MPI_INT,0,7+id,MPI_COMM_WORLD,); printf("%d %d 
> recd\n",me,id); fflush(stdout);
>  MPI_Send(buf[id],N,MPI_INT,0,7+id,MPI_COMM_WORLD); printf("%d %d 
> sent\n",me,id); fflush(stdout);
>}
>  }
> 
>  MPI_Finalize();
> 
>  return 0;
> }
> 
> 
> #!/bin/csh
> 
> mpicc -xopenmp -m64 -O5 main.c
> 
> mpirun -np 2 --mca btl self,sm  ./a.out
> mpirun -np 2 --mca btl self,tcp ./a.out
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

George Bosilca
Research Assistant Professor
Innovative Computing Laboratory
Department of Electrical Engineering and Computer Science
University of Tennessee, Knoxville
http://web.eecs.utk.edu/~bosilca/

Re: [OMPI devel] [Fwd: multi-threaded test]

2011-03-10 Thread Jeff Squyres

If you're trying to make THREAD_MULTIPLE support better, I think that would be 
great.  If your simple test seems to fail over TCP with THREAD_MULTIPLE, then I 
think it's pretty clear that it's broken / needs debugging.

Specifically: if we could have higher confidence in at least a few BTLs' 
support of THREAD_MULTIPLE, that would be great.


On Mar 10, 2011, at 11:23 AM, Eugene Loh wrote:

> Any comments on this?  We wanted to clean up MPI_THREAD_MULTIPLE support in 
> the trunk and port these changes back to 1.5.x, but it's unclear to me what 
> our expectations should be about any MPI_THREAD_MULTIPLE test succeeding.  
> How do we assess (test) our changes?  Or, should we just hardwire thread 
> support to be off, as we have done with progress threads?
> 
>  Original Message 
> Subject:  [OMPI devel] multi-threaded test
> Date: Tue, 08 Mar 2011 11:24:20 -0800
> From: Eugene Loh 
> To:   Open MPI Developers 
> 
> I've been assigned CMR 2728, which is to apply some thread-support 
> changes to 1.5.x.  The trac ticket has amusing language about "needs 
> testing".  I'm not sure what that means.  We rather consistently say 
> that we don't promise anything with regards to true thread support.  We 
> specifically say certain BTLs are off limits and we say things are 
> poorly tested and can be expected to break.  Given all that, what does 
> it mean to test thread support in OMPI?
> 
> One option, specifically in the context of this CMR, is to test only 
> configuration options and so on.  I've done this.
> 
> Another possibility is to confirm that simple run-time tests of 
> multi-threaded message passing succeed.  I'm having trouble with this.
> 
> Attached is a simple test.  It passes over sm but fails over TCP.  (One 
> or both of the initial messages is not received.)
> 
> How high should I set my sights on this?
> 
> 
> #include 
> #include 
> #include 
> #include   /* memset */
> 
> 
> #define N 1
> int main(int argc, char **argv) {
>  int np, me, buf[2][N], provided;
> 
>  /* init some stuff */
>  MPI_Init_thread(, , MPI_THREAD_MULTIPLE, );
>  MPI_Comm_size(MPI_COMM_WORLD,);
>  MPI_Comm_rank(MPI_COMM_WORLD,);
>  if ( provided < MPI_THREAD_MULTIPLE ) MPI_Abort(MPI_COMM_WORLD,-1);
> 
>  /* initialize the buffers */
>  memset(buf[0], 0, N * sizeof(int));
>  memset(buf[1], 0, N * sizeof(int));
> 
>  /* test */
>  #pragma omp parallel num_threads(2)
>  {
>int id = omp_get_thread_num();
>MPI_Status st;
>printf("%d %d in parallel region\n", me, id); fflush(stdout);
> 
>/* pingpong */
>if ( me == 0 ) {
>  MPI_Send(buf[id],N,MPI_INT,1,7+id,MPI_COMM_WORLD); printf("%d %d 
> sent\n",me,id); fflush(stdout);
>  MPI_Recv(buf[id],N,MPI_INT,1,7+id,MPI_COMM_WORLD,); printf("%d %d 
> recd\n",me,id); fflush(stdout);
>} else {
>  MPI_Recv(buf[id],N,MPI_INT,0,7+id,MPI_COMM_WORLD,); printf("%d %d 
> recd\n",me,id); fflush(stdout);
>  MPI_Send(buf[id],N,MPI_INT,0,7+id,MPI_COMM_WORLD); printf("%d %d 
> sent\n",me,id); fflush(stdout);
>}
>  }
> 
>  MPI_Finalize();
> 
>  return 0;
> }
> 
> 
> #!/bin/csh
> 
> mpicc -xopenmp -m64 -O5 main.c
> 
> mpirun -np 2 --mca btl self,sm  ./a.out
> mpirun -np 2 --mca btl self,tcp ./a.out
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] BTL preferred_protocol , large message

2011-03-10 Thread Sylvain Jeaugey


On Wed, 9 Mar 2011, George Bosilca wrote:

One gets multiple non-overlapping BTL (in terms of peers), each with its 
own set of parameters and eventually accepted protocols. Mainly there 
will be one BTL per memory hierarchy.

Pretty cool :-)


I'll cleanup the code and send you a patch.

We'd be happy to review/test/discuss it.

Sylvain

Re: [OMPI devel] turning on progress threads

Re: [OMPI devel] turning on progress threads

Re: [OMPI devel] [Fwd: multi-threaded test]

[OMPI devel] turning on progress threads

Re: [OMPI devel] [Fwd: multi-threaded test]

Re: [OMPI devel] [Fwd: multi-threaded test]

Re: [OMPI devel] [Fwd: multi-threaded test]

Re: [OMPI devel] BTL preferred_protocol , large message

8 matches

Site Navigation

Mail list logo

Footer information