February 2013 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Graph of dependencies in include/
by Barry Smith 14 Feb '13

14 Feb '13

On Feb 14, 2013, at 3:43 PM, Karl Rupp <rupp(a)mcs.anl.gov> wrote: > Hi, > >> I hope this helps in simplifying the include hierarchy and in a >> better separation of modules. It also helps in finding erroneous >> conditional includes: petscfix.h, petscconf.h >> >> >> These two are generated by configure and go in $PETSC_ARCH/include/. > > Okay, I might color them differently then. > >> >> and petscfptimpl.h are included under some circumstances - but don't >> exist. >> >> >> Don't mind that. Barry was eating mushrooms that day. ;-) >> >> https://bitbucket.org/petsc/petsc-dev/commits/70b547a30c706ea4b2828de11dd79… > > :-D I haven't thought about serializing function pointers yet… I got upset one day that trivially restarting an ODE integration in PETSc required the user to write any code at all so decided to do something about. Hence the mushrooms > > Best regards, > Karli

1 0

Re: [petsc-dev] Graph of dependencies in include/
by Karl Rupp 14 Feb '13

14 Feb '13

Hi, > I hope this helps in simplifying the include hierarchy and in a > better separation of modules. It also helps in finding erroneous > conditional includes: petscfix.h, petscconf.h > > > These two are generated by configure and go in $PETSC_ARCH/include/. Okay, I might color them differently then. > > and petscfptimpl.h are included under some circumstances - but don't > exist. > > > Don't mind that. Barry was eating mushrooms that day. ;-) > > https://bitbucket.org/petsc/petsc-dev/commits/70b547a30c706ea4b2828de11dd79… :-D I haven't thought about serializing function pointers yet... Best regards, Karli

1 0

Re: [petsc-dev] Graph of dependencies in include/
by Barry Smith 14 Feb '13

14 Feb '13

Very cool. Barry On Feb 14, 2013, at 2:56 PM, Karl Rupp <rupp(a)mcs.anl.gov> wrote: > Hi guys, > > after some brainstorming with Jed and Barry yesterday on the exercise of drawing an include graph I came up with a script for doing so using GraphViz: > > https://bitbucket.org/petsc/petsc-dev/commits/6b94bbbb78610810e628b868c0c4d… > > Running the script from PETSC_DIR generates the graph. The output obtained on my machine is attached as PDF. > > I hope this helps in simplifying the include hierarchy and in a better separation of modules. It also helps in finding erroneous conditional includes: petscfix.h, petscconf.h and petscfptimpl.h are included under some circumstances - but don't exist. > > Best regards, > Karli > <petsc-include-graph.pdf>

1 0

Re: [petsc-dev] Graph of dependencies in include/
by Jed Brown 14 Feb '13

14 Feb '13

On Thu, Feb 14, 2013 at 2:56 PM, Karl Rupp <rupp(a)mcs.anl.gov> wrote: > I hope this helps in simplifying the include hierarchy and in a better > separation of modules. It also helps in finding erroneous conditional > includes: petscfix.h, petscconf.h These two are generated by configure and go in $PETSC_ARCH/include/. > and petscfptimpl.h are included under some circumstances - but don't exist. Don't mind that. Barry was eating mushrooms that day. ;-) https://bitbucket.org/petsc/petsc-dev/commits/70b547a30c706ea4b2828de11dd79…

1 0

Graph of dependencies in include/
by Karl Rupp 14 Feb '13

14 Feb '13

Hi guys, after some brainstorming with Jed and Barry yesterday on the exercise of drawing an include graph I came up with a script for doing so using GraphViz: https://bitbucket.org/petsc/petsc-dev/commits/6b94bbbb78610810e628b868c0c4d… Running the script from PETSC_DIR generates the graph. The output obtained on my machine is attached as PDF. I hope this helps in simplifying the include hierarchy and in a better separation of modules. It also helps in finding erroneous conditional includes: petscfix.h, petscconf.h and petscfptimpl.h are included under some circumstances - but don't exist. Best regards, Karli

1 0

Re: [petsc-dev] always calling MPI_Init_thread?
by Barry Smith 14 Feb '13

14 Feb '13

On Feb 14, 2013, at 1:36 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Thu, Feb 14, 2013 at 1:25 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > My concern was if a bad implementation always did some terrible thing with locks (even if only one thread would ever exist) thus hurting performance. > > Is there no way to just tell MPI there ARE and WILL be no threads? > > Yeah, MPI_THREAD_SINGLE, but there is nothing to lock when using MPI_THREAD_FUNNELED. I figure that if the user intends to make calls from threads, they should call MPI_Init before PetscInitialize(). Ok, seems fine then. Barry > > > Barry > > On Feb 14, 2013, at 1:22 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > On Thu, Feb 14, 2013 at 1:16 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > Do we really ALWAYS want to call this version even if we are not monkeying with threads at ALL? > > > > Thanks > > > > Barry > > > > ierr = MPI_Initialized(&flag);CHKERRQ(ierr); > > if (!flag) { > > if (PETSC_COMM_WORLD != MPI_COMM_NULL) SETERRQ(PETSC_COMM_SELF,PETSC_ERR_SUP,"You cannot set PETSC_COMM_WORLD if you have not initialized MPI first"); > > #if defined(PETSC_HAVE_MPI_INIT_THREAD) > > { > > PetscMPIInt provided; > > ierr = MPI_Init_thread(argc,args,MPI_THREAD_FUNNELED,&provided);CHKERRQ(ierr); > > } > > #else > > ierr = MPI_Init(argc,args);CHKERRQ(ierr); > > > > The implementation of MPI_Init just probes around the environment and calls MPI_Init_thread. There is no performance advantage of MPI_THREAD_SINGLE over MPI_THREAD_FUNNELED so I think the code here is fine. > >

1 0

Re: [petsc-dev] always calling MPI_Init_thread?
by Jed Brown 14 Feb '13

14 Feb '13

On Thu, Feb 14, 2013 at 1:25 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > My concern was if a bad implementation always did some terrible thing > with locks (even if only one thread would ever exist) thus hurting > performance. > > Is there no way to just tell MPI there ARE and WILL be no threads? > Yeah, MPI_THREAD_SINGLE, but there is nothing to lock when using MPI_THREAD_FUNNELED. I figure that if the user intends to make calls from threads, they should call MPI_Init before PetscInitialize(). > > Barry > > On Feb 14, 2013, at 1:22 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > On Thu, Feb 14, 2013 at 1:16 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > Do we really ALWAYS want to call this version even if we are not > monkeying with threads at ALL? > > > > Thanks > > > > Barry > > > > ierr = MPI_Initialized(&flag);CHKERRQ(ierr); > > if (!flag) { > > if (PETSC_COMM_WORLD != MPI_COMM_NULL) > SETERRQ(PETSC_COMM_SELF,PETSC_ERR_SUP,"You cannot set PETSC_COMM_WORLD if > you have not initialized MPI first"); > > #if defined(PETSC_HAVE_MPI_INIT_THREAD) > > { > > PetscMPIInt provided; > > ierr = > MPI_Init_thread(argc,args,MPI_THREAD_FUNNELED,&provided);CHKERRQ(ierr); > > } > > #else > > ierr = MPI_Init(argc,args);CHKERRQ(ierr); > > > > The implementation of MPI_Init just probes around the environment and > calls MPI_Init_thread. There is no performance advantage of > MPI_THREAD_SINGLE over MPI_THREAD_FUNNELED so I think the code here is fine. > >

1 0

Re: [petsc-dev] always calling MPI_Init_thread?
by Barry Smith 14 Feb '13

14 Feb '13

My concern was if a bad implementation always did some terrible thing with locks (even if only one thread would ever exist) thus hurting performance. Is there no way to just tell MPI there ARE and WILL be no threads? Barry On Feb 14, 2013, at 1:22 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Thu, Feb 14, 2013 at 1:16 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > Do we really ALWAYS want to call this version even if we are not monkeying with threads at ALL? > > Thanks > > Barry > > ierr = MPI_Initialized(&flag);CHKERRQ(ierr); > if (!flag) { > if (PETSC_COMM_WORLD != MPI_COMM_NULL) SETERRQ(PETSC_COMM_SELF,PETSC_ERR_SUP,"You cannot set PETSC_COMM_WORLD if you have not initialized MPI first"); > #if defined(PETSC_HAVE_MPI_INIT_THREAD) > { > PetscMPIInt provided; > ierr = MPI_Init_thread(argc,args,MPI_THREAD_FUNNELED,&provided);CHKERRQ(ierr); > } > #else > ierr = MPI_Init(argc,args);CHKERRQ(ierr); > > The implementation of MPI_Init just probes around the environment and calls MPI_Init_thread. There is no performance advantage of MPI_THREAD_SINGLE over MPI_THREAD_FUNNELED so I think the code here is fine.

1 0

Re: [petsc-dev] always calling MPI_Init_thread?
by Jed Brown 14 Feb '13

14 Feb '13

On Thu, Feb 14, 2013 at 1:16 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > Do we really ALWAYS want to call this version even if we are not > monkeying with threads at ALL? > > Thanks > > Barry > > ierr = MPI_Initialized(&flag);CHKERRQ(ierr); > if (!flag) { > if (PETSC_COMM_WORLD != MPI_COMM_NULL) > SETERRQ(PETSC_COMM_SELF,PETSC_ERR_SUP,"You cannot set PETSC_COMM_WORLD if > you have not initialized MPI first"); > #if defined(PETSC_HAVE_MPI_INIT_THREAD) > { > PetscMPIInt provided; > ierr = > MPI_Init_thread(argc,args,MPI_THREAD_FUNNELED,&provided);CHKERRQ(ierr); > } > #else > ierr = MPI_Init(argc,args);CHKERRQ(ierr); > The implementation of MPI_Init just probes around the environment and calls MPI_Init_thread. There is no performance advantage of MPI_THREAD_SINGLE over MPI_THREAD_FUNNELED so I think the code here is fine.

1 0

always calling MPI_Init_thread?
by Barry Smith 14 Feb '13

14 Feb '13

Do we really ALWAYS want to call this version even if we are not monkeying with threads at ALL? Thanks Barry ierr = MPI_Initialized(&flag);CHKERRQ(ierr); if (!flag) { if (PETSC_COMM_WORLD != MPI_COMM_NULL) SETERRQ(PETSC_COMM_SELF,PETSC_ERR_SUP,"You cannot set PETSC_COMM_WORLD if you have not initialized MPI first"); #if defined(PETSC_HAVE_MPI_INIT_THREAD) { PetscMPIInt provided; ierr = MPI_Init_thread(argc,args,MPI_THREAD_FUNNELED,&provided);CHKERRQ(ierr); } #else ierr = MPI_Init(argc,args);CHKERRQ(ierr); #endif

1 0