May 2008 - petsc-dev - mailman3.cels.anl.gov

Re: Reporting cpu times to profile KSPSolve (and others)
by Matthew Knepley 08 May '08

08 May '08

On Thu, May 8, 2008 at 10:09 PM, Dave May <dave.mayhem23(a)gmail.com> wrote: > Hey petsc folk, > What is the best way to obtain timing information to profile the > performance > of KSPSolve (or SNESSolve)? Currently I have written some specific KSP > monitors, > but it I think it would be useful to have access to this information all the > time without > having to go through the monitor. It seems like each object should know how > to time > some of its operations. > > It would be very useful to have functions such as > KSPGetCPUTime(KSP ksp,PetscLogDouble *time) > to report the total solution time required by the KSPSolve() and > KSPGetCPUTimeHistory(KSP ksp,PetscLogDouble *time[],PetscInt *na) > which is like KSPGetResidualHistory() but returns the accumulated cpu time > for each > iterate > > It would also be useful to have a default KSP monitor which could report the > time per iterate > or accumulate time. For example something like > 40 KSP Residual norm 1.519638506430e-01 Time 1.000000000000e-03 > 41 KSP Residual norm 1.510346481853e-01 Time 1.510346481853e-02 > > Is there a better approach to what I've been doing and are there plans to > add any > additional features to help profile individual operations on each object? Maybe you could motivate it by giving a use case? So far, I have never needed anything but the KSPSolve() event and stages to separately aggregate different types of solves. Matt > Cheers, > Dave -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Reporting cpu times to profile KSPSolve (and others)
by Dave May 08 May '08

08 May '08

Hey petsc folk, What is the best way to obtain timing information to profile the performance of KSPSolve (or SNESSolve)? Currently I have written some specific KSP monitors, but it I think it would be useful to have access to this information all the time without having to go through the monitor. It seems like each object should know how to time some of its operations. It would be very useful to have functions such as KSPGetCPUTime(KSP ksp,PetscLogDouble *time) to report the total solution time required by the KSPSolve() and KSPGetCPUTimeHistory(KSP ksp,PetscLogDouble *time[],PetscInt *na) which is like KSPGetResidualHistory() but returns the accumulated cpu time for each iterate It would also be useful to have a default KSP monitor which could report the time per iterate or accumulate time. For example something like 40 KSP Residual norm 1.519638506430e-01 Time 1.000000000000e-03 41 KSP Residual norm 1.510346481853e-01 Time 1.510346481853e-02 Is there a better approach to what I've been doing and are there plans to add any additional features to help profile individual operations on each object? Cheers, Dave

1 0

Re: How come it is PetscEvent but all the routines that act on it are PetscLogEventXXXX()?
by Barry Smith 07 May '08

07 May '08

On May 7, 2008, at 10:48 AM, Richard Tran Mills wrote: > Barry, > > I like the the suggestion to change PetscLogEvent* to PetscEvent*, > but to be consistent with naming then I think we would also need to > change PetscLogStage* to PetscStage*, etc. > I don't use that too much so I haven't thought about it. But "stage" is an int not a PetscStage so my rule about method names and objects doesn't apply. It appears "stage" should become a PetscStage and then the Log would be dropped from PetscLogStage .... Barry > Just my 0.5 cents. > > --Richard > > Barry Smith wrote: >> On May 5, 2008, at 7:39 PM, Matthew Knepley wrote: >>> Actually, I would argue that these methods do not actually act on >>> PetscEvent >>> at all (which is just an integer), but rather on a PetscLog. That >>> is why I named >>> them that way. >> The namage has to be consistent with any normal Joe's thinking >> about the usage, >> not based on some implementation issue that only you know about. >> Names are for >> users, not for the guru developers. Guru developers could name >> their variables and >> functions a1 to a2303 and have no problem maintaining the code. >> I think the macro names should be changed to PetscEventBegin.... not >> PetscLogEventBegin.... based on the policy in PETSc that "methods" >> on "objects" >> start with the name of the objects: e.g. MatMult(Mat,....) The user >> shouldn't know >> or care that PetscEvent is an int and not a PetscEvent or >> PetscLogEvent object. >> Barry >> We could instead change PetscEvent to PetscLogEvent but I think >> PetscEvent >> is clear enough without the Log in it. >>> >>> >>> Matt >>> >>> On Sat, May 3, 2008 at 6:26 PM, Barry Smith <bsmith(a)mcs.anl.gov> >>> wrote: >>>> >>>> Doesn't seem right. >>>> >>>> Barry >>>> >>>> >>> >>> >>> >>> -- >>> What most experimenters take for granted before they begin their >>> experiments is infinitely more interesting than any results to which >>> their experiments lead. >>> -- Norbert Wiener >>> > > > -- > Richard Tran Mills, Ph.D. | E-mail: rmills(a)climate.ornl.gov > Computational Scientist | Phone: (865) 241-3198 > Computational Earth Sciences Group | Fax: (865) 574-0405 > Oak Ridge National Laboratory | http://climate.ornl.gov/~rmills >

1 0

Re: How come it is PetscEvent but all the routines that act on it are PetscLogEventXXXX()?
by Richard Tran Mills 07 May '08

07 May '08

Barry, I like the the suggestion to change PetscLogEvent* to PetscEvent*, but to be consistent with naming then I think we would also need to change PetscLogStage* to PetscStage*, etc. Just my 0.5 cents. --Richard Barry Smith wrote: > > On May 5, 2008, at 7:39 PM, Matthew Knepley wrote: > >> Actually, I would argue that these methods do not actually act on >> PetscEvent >> at all (which is just an integer), but rather on a PetscLog. That is >> why I named >> them that way. > > The namage has to be consistent with any normal Joe's thinking about > the usage, > not based on some implementation issue that only you know about. Names > are for > users, not for the guru developers. Guru developers could name their > variables and > functions a1 to a2303 and have no problem maintaining the code. > > I think the macro names should be changed to PetscEventBegin.... not > PetscLogEventBegin.... based on the policy in PETSc that "methods" on > "objects" > start with the name of the objects: e.g. MatMult(Mat,....) The user > shouldn't know > or care that PetscEvent is an int and not a PetscEvent or PetscLogEvent > object. > > Barry > > We could instead change PetscEvent to PetscLogEvent but I think PetscEvent > is clear enough without the Log in it. > > >> >> >> Matt >> >> On Sat, May 3, 2008 at 6:26 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >>> >>> Doesn't seem right. >>> >>> Barry >>> >>> >> >> >> >> -- >> What most experimenters take for granted before they begin their >> experiments is infinitely more interesting than any results to which >> their experiments lead. >> -- Norbert Wiener >> > -- Richard Tran Mills, Ph.D. | E-mail: rmills(a)climate.ornl.gov Computational Scientist | Phone: (865) 241-3198 Computational Earth Sciences Group | Fax: (865) 574-0405 Oak Ridge National Laboratory | http://climate.ornl.gov/~rmills

1 0

Re: How come it is PetscEvent but all the routines that act on it are PetscLogEventXXXX()?
by Lisandro Dalcin 06 May '08

06 May '08

Or your can #define ! ... just a joke (a not a really good one)... On 5/6/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On May 5, 2008, at 7:39 PM, Matthew Knepley wrote: > > > > Actually, I would argue that these methods do not actually act on > PetscEvent > > at all (which is just an integer), but rather on a PetscLog. That is why I > named > > them that way. > > > > The namage has to be consistent with any normal Joe's thinking about the > usage, > not based on some implementation issue that only you know about. Names are > for > users, not for the guru developers. Guru developers could name their > variables and > functions a1 to a2303 and have no problem maintaining the code. > > I think the macro names should be changed to PetscEventBegin.... not > PetscLogEventBegin.... based on the policy in PETSc that "methods" on > "objects" > start with the name of the objects: e.g. MatMult(Mat,....) The user > shouldn't know > or care that PetscEvent is an int and not a PetscEvent or PetscLogEvent > object. > > Barry > > We could instead change PetscEvent to PetscLogEvent but I think PetscEvent > is clear enough without the Log in it. > > > > > > > > > > Matt > > > > On Sat, May 3, 2008 at 6:26 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > > > Doesn't seem right. > > > > > > Barry > > > > > > > > > > > > > > > > > -- > > What most experimenters take for granted before they begin their > > experiments is infinitely more interesting than any results to which > > their experiments lead. > > -- Norbert Wiener > > > > > > -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: How come it is PetscEvent but all the routines that act on it are PetscLogEventXXXX()?
by Barry Smith 06 May '08

06 May '08

On May 5, 2008, at 7:39 PM, Matthew Knepley wrote: > Actually, I would argue that these methods do not actually act on > PetscEvent > at all (which is just an integer), but rather on a PetscLog. That is > why I named > them that way. The namage has to be consistent with any normal Joe's thinking about the usage, not based on some implementation issue that only you know about. Names are for users, not for the guru developers. Guru developers could name their variables and functions a1 to a2303 and have no problem maintaining the code. I think the macro names should be changed to PetscEventBegin.... not PetscLogEventBegin.... based on the policy in PETSc that "methods" on "objects" start with the name of the objects: e.g. MatMult(Mat,....) The user shouldn't know or care that PetscEvent is an int and not a PetscEvent or PetscLogEvent object. Barry We could instead change PetscEvent to PetscLogEvent but I think PetscEvent is clear enough without the Log in it. > > > Matt > > On Sat, May 3, 2008 at 6:26 PM, Barry Smith <bsmith(a)mcs.anl.gov> > wrote: >> >> Doesn't seem right. >> >> Barry >> >> > > > > -- > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which > their experiments lead. > -- Norbert Wiener >

1 0

Re: How come it is PetscEvent but all the routines that act on it are PetscLogEventXXXX()?
by Matthew Knepley 05 May '08

05 May '08

Actually, I would argue that these methods do not actually act on PetscEvent at all (which is just an integer), but rather on a PetscLog. That is why I named them that way. Matt On Sat, May 3, 2008 at 6:26 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Doesn't seem right. > > Barry > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: now impossible to debug code that uses PETSc shared libraries?
by Matthew Knepley 04 May '08

04 May '08

On Sat, May 3, 2008 at 2:50 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > They may have changed things on Leopard. I have had a problem like this before on Linux. It was a mismatch between the compiler and debugger. Google might have either a fix for this bug, or at least the compatible versions of gcc and gdb for Leopard. Matt > Barry > > > > On May 3, 2008, at 2:00 AM, Satish Balay wrote: > > > > On Sat, 3 May 2008, Satish Balay wrote: > > > > > > > On Fri, 2 May 2008, Barry Smith wrote: > > > > > > > > > > apple > > > > > > > > > > Appears to work fine on 10.4 ppc machine - I have access to. > > > > > > > Also works on 10.4 Intel machine > > > > Satish > > > > -------------------------------------------- > > > > videh:~/petsc-dev/src/ksp/ksp/examples/tutorials balay$ ls > $PETSC_DIR/$PETSC_ARCH/lib > > foo libpetsc.dylib libpetscdm.dylib > libpetscmat.dylib libpetscts.dylib > > libmpiuni.a libpetsccontrib.dylib libpetscksp.dylib > libpetscsnes.dylib libpetscvec.dylib > > videh:~/petsc-dev/src/ksp/ksp/examples/tutorials balay$ make ex2 > > gcc -o ex2.o -c -fPIC -Wall -Wwrite-strings -Wno-long-double > -Wno-strict-aliasing -g3 -I/Users/balay/petsc-dev/src/dm/mesh/sieve > -I/Users/balay/petsc-dev > -I/Users/balay/petsc-dev/darwin8.11.1-c-debug/include > -I/Users/balay/petsc-dev/include > -I/Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include > -I/Users/balay/petsc-dev/include/mpiuni > -D__SDIR__="src/ksp/ksp/examples/tutorials/" ex2.c > > gcc -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress > -fPIC -Wall -Wwrite-strings -Wno-long-double -Wno-strict-aliasing -g3 -o > ex2 ex2.o -L/Users/balay/petsc-dev/darwin8.11.1-c-debug/lib > -L/Users/balay/petsc-dev/darwin8.11.1-c-debug/lib -lpetscksp -lpetscdm > -lpetscmat -lpetscvec -lpetsc -L/usr/X11R6/lib -lX11 > -L/Users/balay/petsc-dev/darwin8.11.1-c-debug/lib > -L/Users/balay/petsc-dev/darwin8.11.1-c-debug/lib -lmpiuni -llapack -lblas > > /bin/rm -f ex2.o > > videh:~/petsc-dev/src/ksp/ksp/examples/tutorials balay$ gdb ex2 > > GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:50:43 GMT > 2006) > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you > are > > welcome to change it and/or distribute copies of it under certain > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for > details. > > This GDB was configured as "i386-apple-darwin"...Reading symbols for > shared libraries .......... done > > > > (gdb) b MatMult > > Breakpoint 1 at 0x184cfe: file matrix.c, line 1687. > > (gdb) r > > Starting program: > /Users/balay/petsc-dev/src/ksp/ksp/examples/tutorials/ex2 > > Reading symbols for shared libraries ..+.+++++ done > > Breakpoint 1 at 0x118cd0c: file matrix.c, line 1690. > > > > Breakpoint 1, MatMult (mat=0x1808f30, x=0x180b930, y=0x180fb30) at > matrix.c:1690 > > 1690 PetscFunctionBegin; > > (gdb) where > > #0 MatMult (mat=0x1808f30, x=0x180b930, y=0x180fb30) at matrix.c:1690 > > #1 0x00002746 in main (argc=1, args=0xbffffae0) at ex2.c:141 > > (gdb) list > > 1685 @*/ > > 1686 PetscErrorCode PETSCMAT_DLLEXPORT MatMult(Mat mat,Vec x,Vec y) > > 1687 { > > 1688 PetscErrorCode ierr; > > 1689 > > 1690 PetscFunctionBegin; > > 1691 PetscValidHeaderSpecific(mat,MAT_COOKIE,1); > > 1692 PetscValidType(mat,1); > > 1693 PetscValidHeaderSpecific(x,VEC_COOKIE,2); > > 1694 PetscValidHeaderSpecific(y,VEC_COOKIE,3); > > (gdb) > > > > > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

How come it is PetscEvent but all the routines that act on it are PetscLogEventXXXX()?
by Barry Smith 03 May '08

03 May '08

Doesn't seem right. Barry

1 0

Re: now impossible to debug code that uses PETSc shared libraries?
by Barry Smith 03 May '08

03 May '08

They may have changed things on Leopard. Barry On May 3, 2008, at 2:00 AM, Satish Balay wrote: > On Sat, 3 May 2008, Satish Balay wrote: > >> On Fri, 2 May 2008, Barry Smith wrote: >> >>> apple >> >> Appears to work fine on 10.4 ppc machine - I have access to. > > Also works on 10.4 Intel machine > > Satish > > -------------------------------------------- > > videh:~/petsc-dev/src/ksp/ksp/examples/tutorials balay$ ls > $PETSC_DIR/$PETSC_ARCH/lib > foo libpetsc.dylib > libpetscdm.dylib libpetscmat.dylib libpetscts.dylib > libmpiuni.a libpetsccontrib.dylib > libpetscksp.dylib libpetscsnes.dylib libpetscvec.dylib > videh:~/petsc-dev/src/ksp/ksp/examples/tutorials balay$ make ex2 > gcc -o ex2.o -c -fPIC -Wall -Wwrite-strings -Wno-long-double -Wno- > strict-aliasing -g3 -I/Users/balay/petsc-dev/src/dm/mesh/sieve -I/ > Users/balay/petsc-dev -I/Users/balay/petsc-dev/darwin8.11.1-c-debug/ > include -I/Users/balay/petsc-dev/include -I/Developer/SDKs/ > MacOSX10.4u.sdk/usr/X11R6/include -I/Users/balay/petsc-dev/include/ > mpiuni -D__SDIR__="src/ksp/ksp/examples/tutorials/" ex2.c > gcc -Wl,-multiply_defined,suppress -Wl,-multiply_defined - > Wl,suppress -fPIC -Wall -Wwrite-strings -Wno-long-double -Wno- > strict-aliasing -g3 -o ex2 ex2.o -L/Users/balay/petsc-dev/ > darwin8.11.1-c-debug/lib -L/Users/balay/petsc-dev/darwin8.11.1-c- > debug/lib -lpetscksp -lpetscdm -lpetscmat -lpetscvec -lpetsc -L/ > usr/X11R6/lib -lX11 -L/Users/balay/petsc-dev/darwin8.11.1-c-debug/ > lib -L/Users/balay/petsc-dev/darwin8.11.1-c-debug/lib -lmpiuni - > llapack -lblas > /bin/rm -f ex2.o > videh:~/petsc-dev/src/ksp/ksp/examples/tutorials balay$ gdb ex2 > GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:50:43 > GMT 2006) > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-apple-darwin"...Reading symbols for > shared libraries .......... done > > (gdb) b MatMult > Breakpoint 1 at 0x184cfe: file matrix.c, line 1687. > (gdb) r > Starting program: /Users/balay/petsc-dev/src/ksp/ksp/examples/ > tutorials/ex2 > Reading symbols for shared libraries ..+.+++++ done > Breakpoint 1 at 0x118cd0c: file matrix.c, line 1690. > > Breakpoint 1, MatMult (mat=0x1808f30, x=0x180b930, y=0x180fb30) at > matrix.c:1690 > 1690 PetscFunctionBegin; > (gdb) where > #0 MatMult (mat=0x1808f30, x=0x180b930, y=0x180fb30) at matrix.c:1690 > #1 0x00002746 in main (argc=1, args=0xbffffae0) at ex2.c:141 > (gdb) list > 1685 @*/ > 1686 PetscErrorCode PETSCMAT_DLLEXPORT MatMult(Mat mat,Vec x,Vec y) > 1687 { > 1688 PetscErrorCode ierr; > 1689 > 1690 PetscFunctionBegin; > 1691 PetscValidHeaderSpecific(mat,MAT_COOKIE,1); > 1692 PetscValidType(mat,1); > 1693 PetscValidHeaderSpecific(x,VEC_COOKIE,2); > 1694 PetscValidHeaderSpecific(y,VEC_COOKIE,3); > (gdb) >

1 0