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

Re: [petsc-dev] VecAXPY() in loops in TS
by Barry Smith 18 Feb '11

18 Feb '11

Added to projects.html list Barry On Feb 18, 2011, at 5:34 PM, Jed Brown wrote: > On Sat, Feb 19, 2011 at 00:24, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Even adjusting the array passed in will be worth it. > > Yes, the work to futz around with the small array is tiny compared to the cost of streaming the vector through extra times. > > > Should MAXPY have an optional constant scale factor, does it come up enough? > > It looks like about half of the uses in PETSc are preceded by a loop to apply some constant factor, so I think such a parameter would be worthwhile.

1 0

Re: [petsc-dev] VecAXPY() in loops in TS
by Jed Brown 18 Feb '11

18 Feb '11

On Sat, Feb 19, 2011 at 00:24, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Even adjusting the array passed in will be worth it. > Yes, the work to futz around with the small array is tiny compared to the cost of streaming the vector through extra times. > > Should MAXPY have an optional constant scale factor, does it come up > enough? > It looks like about half of the uses in PETSc are preceded by a loop to apply some constant factor, so I think such a parameter would be worthwhile.

1 0

Re: [petsc-dev] VecAXPY() in loops in TS
by Barry Smith 18 Feb '11

18 Feb '11

Even adjusting the array passed in will be worth it. Should MAXPY have an optional constant scale factor, does it come up enough? Barry On Feb 18, 2011, at 5:03 PM, Jed Brown wrote: > On Fri, Feb 18, 2011 at 19:48, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Can some of the VecAXPY() calls in loops in TS be replaced with single VecMAXPY() calls? For example > > for (j=0; j<r; j++) { > ierr = VecAXPY(gl->Z,-shift*u[i*r+j],X[j]);CHKERRQ(ierr); > } > > They can, but we would have to create a temporary array to hold the coefficients and run the loop to fill the coefficients into that array. I recall intending to do that when I first wrote this, but clearly it never happened.

1 0

Re: [petsc-dev] VecAXPY() in loops in TS
by Jed Brown 18 Feb '11

18 Feb '11

On Fri, Feb 18, 2011 at 19:48, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Can some of the VecAXPY() calls in loops in TS be replaced with single > VecMAXPY() calls? For example > > for (j=0; j<r; j++) { > ierr = VecAXPY(gl->Z,-shift*u[i*r+j],X[j]);CHKERRQ(ierr); > } > They can, but we would have to create a temporary array to hold the coefficients and run the loop to fill the coefficients into that array. I recall intending to do that when I first wrote this, but clearly it never happened.

1 0

VecAXPY() in loops in TS
by Barry Smith 18 Feb '11

18 Feb '11

Can some of the VecAXPY() calls in loops in TS be replaced with single VecMAXPY() calls? For example for (j=0; j<r; j++) { ierr = VecAXPY(gl->Z,-shift*u[i*r+j],X[j]);CHKERRQ(ierr); } Just asking, Barry

1 0

Re: [petsc-dev] XXXDestroy() mistaken design in PETSc
by Barry Smith 15 Feb '11

15 Feb '11

On Feb 15, 2011, at 8:23 PM, Matthew Knepley wrote: > On Tue, Feb 15, 2011 at 8:18 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 15, 2011, at 8:12 PM, Matthew Knepley wrote: > > > On Tue, Feb 15, 2011 at 8:10 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > On Feb 15, 2011, at 8:03 PM, Matthew Knepley wrote: > > > > > On Tue, Feb 15, 2011 at 7:58 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > On Feb 15, 2011, at 5:26 PM, Matthew Knepley wrote: > > > > > > > On Tue, Feb 15, 2011 at 4:47 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > > > In MPI one calls MPI_Comm_free(&comm) to allow the MPI implementation to set the pointer explicitly to 0 after the object is destroyed. > > > > > > > > In Petsc XXXDestroy() does not pass the pointer (because it seemed too unnatural to me in 1994) thus not allowing 0ing the pointer. > > > > > > > > Was this a bad design decision? Should it be revisited? > > > > > > > > Barry > > > > > > > > Two use cases > > > > > > > > 1) error detection when someone tries to reuse a freed object > > > > > > > > We catch this with other error detection. I do not think we would gain much here. > > > > > > No really. If I do MatDestroy(mat); MatMult(mat,x,y); then it is possible that MatMutl() will crash while looking around inside where mat points. If MatDestroy(&mat); zeroed mat then MatMult(mat,x,y) could do the safe test of if (!mat) nice error message. > > > > > > I agree, but the immediate type test at the start of MatMult() has caught most things for me. I do not consider > > > double-free a recoverable error, so a SEGV is alright here as well. > > > > If I am sitting in front of a Matlab or Python scripting session I would much prefer an error that returns to my Matlab or Python prompt so I can keep on doing stuff versus a crash that requires restarting Matlab or Python. > > > > I do not disagree with this. However, we do have to weigh the effectiveness of changes that break every PETSc > > code ever written. > > True. But just because I did something stupid 16 years ago doesn't mean we should live with it forever. What about introducing XXXXFree() and moving to using it exclusively in PETSc but continuing to support XXXDestroy() for years. > > That is a good solution. I guess I am alright with XXXFree() although I like Destroy better. I can't > think of a better name. To make live hard we'll make a new version of PetscFree() that zeros the pointer and call it PetscDestroy() :-) > Should be release before we do this? Yes Barry > > Matt > > > > > Matt > > > > > > Barry > > > > > > > > Matt > > > > > > > > > Barry > > > > > > > > > > > 2) when removing some objects from a data structure that will be used data one currently needs to do > > > > > > > > XXXXDestroy(mystruct->something);CHKERRQ(ierr); mystruct->something = 0; > > > > > > > > instead of the cleaner XXXDestroy(&mystruct->something);CHKERRQ(ierr); > > > > > > > > True, but again I do not think the win is large. > > > > > > > > Matt > > > > > > > > -- > > > > 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 > > > > > > > > > > > > > > > -- > > > 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 > > > > > > > > > > -- > > 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 > > > > > -- > 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: [petsc-dev] XXXDestroy() mistaken design in PETSc
by Matthew Knepley 15 Feb '11

15 Feb '11

On Tue, Feb 15, 2011 at 8:18 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 15, 2011, at 8:12 PM, Matthew Knepley wrote: > > > On Tue, Feb 15, 2011 at 8:10 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > On Feb 15, 2011, at 8:03 PM, Matthew Knepley wrote: > > > > > On Tue, Feb 15, 2011 at 7:58 PM, Barry Smith <bsmith(a)mcs.anl.gov> > wrote: > > > > > > On Feb 15, 2011, at 5:26 PM, Matthew Knepley wrote: > > > > > > > On Tue, Feb 15, 2011 at 4:47 PM, Barry Smith <bsmith(a)mcs.anl.gov> > wrote: > > > > > > > > In MPI one calls MPI_Comm_free(&comm) to allow the MPI > implementation to set the pointer explicitly to 0 after the object is > destroyed. > > > > > > > > In Petsc XXXDestroy() does not pass the pointer (because it seemed > too unnatural to me in 1994) thus not allowing 0ing the pointer. > > > > > > > > Was this a bad design decision? Should it be revisited? > > > > > > > > Barry > > > > > > > > Two use cases > > > > > > > > 1) error detection when someone tries to reuse a freed object > > > > > > > > We catch this with other error detection. I do not think we would > gain much here. > > > > > > No really. If I do MatDestroy(mat); MatMult(mat,x,y); then it is > possible that MatMutl() will crash while looking around inside where mat > points. If MatDestroy(&mat); zeroed mat then MatMult(mat,x,y) could do the > safe test of if (!mat) nice error message. > > > > > > I agree, but the immediate type test at the start of MatMult() has > caught most things for me. I do not consider > > > double-free a recoverable error, so a SEGV is alright here as well. > > > > If I am sitting in front of a Matlab or Python scripting session I would > much prefer an error that returns to my Matlab or Python prompt so I can > keep on doing stuff versus a crash that requires restarting Matlab or > Python. > > > > I do not disagree with this. However, we do have to weigh the > effectiveness of changes that break every PETSc > > code ever written. > > True. But just because I did something stupid 16 years ago doesn't mean > we should live with it forever. What about introducing XXXXFree() and moving > to using it exclusively in PETSc but continuing to support XXXDestroy() for > years. > That is a good solution. I guess I am alright with XXXFree() although I like Destroy better. I can't think of a better name. Should be release before we do this? Matt > > > > Matt > > > > > > Barry > > > > > > > > Matt > > > > > > > > > Barry > > > > > > > > > > > 2) when removing some objects from a data structure that will be used > data one currently needs to do > > > > > > > > XXXXDestroy(mystruct->something);CHKERRQ(ierr); mystruct->something > = 0; > > > > > > > > instead of the cleaner > XXXDestroy(&mystruct->something);CHKERRQ(ierr); > > > > > > > > True, but again I do not think the win is large. > > > > > > > > Matt > > > > > > > > -- > > > > 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 > > > > > > > > > > > > > > > -- > > > 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 > > > > > > > > > > -- > > 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 > > -- 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: [petsc-dev] XXXDestroy() mistaken design in PETSc
by Barry Smith 15 Feb '11

15 Feb '11

On Feb 15, 2011, at 8:12 PM, Matthew Knepley wrote: > On Tue, Feb 15, 2011 at 8:10 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 15, 2011, at 8:03 PM, Matthew Knepley wrote: > > > On Tue, Feb 15, 2011 at 7:58 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > On Feb 15, 2011, at 5:26 PM, Matthew Knepley wrote: > > > > > On Tue, Feb 15, 2011 at 4:47 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > In MPI one calls MPI_Comm_free(&comm) to allow the MPI implementation to set the pointer explicitly to 0 after the object is destroyed. > > > > > > In Petsc XXXDestroy() does not pass the pointer (because it seemed too unnatural to me in 1994) thus not allowing 0ing the pointer. > > > > > > Was this a bad design decision? Should it be revisited? > > > > > > Barry > > > > > > Two use cases > > > > > > 1) error detection when someone tries to reuse a freed object > > > > > > We catch this with other error detection. I do not think we would gain much here. > > > > No really. If I do MatDestroy(mat); MatMult(mat,x,y); then it is possible that MatMutl() will crash while looking around inside where mat points. If MatDestroy(&mat); zeroed mat then MatMult(mat,x,y) could do the safe test of if (!mat) nice error message. > > > > I agree, but the immediate type test at the start of MatMult() has caught most things for me. I do not consider > > double-free a recoverable error, so a SEGV is alright here as well. > > If I am sitting in front of a Matlab or Python scripting session I would much prefer an error that returns to my Matlab or Python prompt so I can keep on doing stuff versus a crash that requires restarting Matlab or Python. > > I do not disagree with this. However, we do have to weigh the effectiveness of changes that break every PETSc > code ever written. True. But just because I did something stupid 16 years ago doesn't mean we should live with it forever. What about introducing XXXXFree() and moving to using it exclusively in PETSc but continuing to support XXXDestroy() for years. > > Matt > > > Barry > > > > > Matt > > > > > > Barry > > > > > > > > 2) when removing some objects from a data structure that will be used data one currently needs to do > > > > > > XXXXDestroy(mystruct->something);CHKERRQ(ierr); mystruct->something = 0; > > > > > > instead of the cleaner XXXDestroy(&mystruct->something);CHKERRQ(ierr); > > > > > > True, but again I do not think the win is large. > > > > > > Matt > > > > > > -- > > > 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 > > > > > > > > > > -- > > 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 > > > > > -- > 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: [petsc-dev] XXXDestroy() mistaken design in PETSc
by Matthew Knepley 15 Feb '11

15 Feb '11

On Tue, Feb 15, 2011 at 8:10 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 15, 2011, at 8:03 PM, Matthew Knepley wrote: > > > On Tue, Feb 15, 2011 at 7:58 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > On Feb 15, 2011, at 5:26 PM, Matthew Knepley wrote: > > > > > On Tue, Feb 15, 2011 at 4:47 PM, Barry Smith <bsmith(a)mcs.anl.gov> > wrote: > > > > > > In MPI one calls MPI_Comm_free(&comm) to allow the MPI implementation > to set the pointer explicitly to 0 after the object is destroyed. > > > > > > In Petsc XXXDestroy() does not pass the pointer (because it seemed too > unnatural to me in 1994) thus not allowing 0ing the pointer. > > > > > > Was this a bad design decision? Should it be revisited? > > > > > > Barry > > > > > > Two use cases > > > > > > 1) error detection when someone tries to reuse a freed object > > > > > > We catch this with other error detection. I do not think we would gain > much here. > > > > No really. If I do MatDestroy(mat); MatMult(mat,x,y); then it is > possible that MatMutl() will crash while looking around inside where mat > points. If MatDestroy(&mat); zeroed mat then MatMult(mat,x,y) could do the > safe test of if (!mat) nice error message. > > > > I agree, but the immediate type test at the start of MatMult() has caught > most things for me. I do not consider > > double-free a recoverable error, so a SEGV is alright here as well. > > If I am sitting in front of a Matlab or Python scripting session I would > much prefer an error that returns to my Matlab or Python prompt so I can > keep on doing stuff versus a crash that requires restarting Matlab or > Python. I do not disagree with this. However, we do have to weigh the effectiveness of changes that break every PETSc code ever written. Matt > > Barry > > > > > Matt > > > > > > Barry > > > > > > > > 2) when removing some objects from a data structure that will be used > data one currently needs to do > > > > > > XXXXDestroy(mystruct->something);CHKERRQ(ierr); mystruct->something = > 0; > > > > > > instead of the cleaner XXXDestroy(&mystruct->something);CHKERRQ(ierr); > > > > > > True, but again I do not think the win is large. > > > > > > Matt > > > > > > -- > > > 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 > > > > > > > > > > -- > > 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 > > -- 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: [petsc-dev] XXXDestroy() mistaken design in PETSc
by Barry Smith 15 Feb '11

15 Feb '11

On Feb 15, 2011, at 8:03 PM, Matthew Knepley wrote: > On Tue, Feb 15, 2011 at 7:58 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Feb 15, 2011, at 5:26 PM, Matthew Knepley wrote: > > > On Tue, Feb 15, 2011 at 4:47 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > In MPI one calls MPI_Comm_free(&comm) to allow the MPI implementation to set the pointer explicitly to 0 after the object is destroyed. > > > > In Petsc XXXDestroy() does not pass the pointer (because it seemed too unnatural to me in 1994) thus not allowing 0ing the pointer. > > > > Was this a bad design decision? Should it be revisited? > > > > Barry > > > > Two use cases > > > > 1) error detection when someone tries to reuse a freed object > > > > We catch this with other error detection. I do not think we would gain much here. > > No really. If I do MatDestroy(mat); MatMult(mat,x,y); then it is possible that MatMutl() will crash while looking around inside where mat points. If MatDestroy(&mat); zeroed mat then MatMult(mat,x,y) could do the safe test of if (!mat) nice error message. > > I agree, but the immediate type test at the start of MatMult() has caught most things for me. I do not consider > double-free a recoverable error, so a SEGV is alright here as well. If I am sitting in front of a Matlab or Python scripting session I would much prefer an error that returns to my Matlab or Python prompt so I can keep on doing stuff versus a crash that requires restarting Matlab or Python. Barry > > Matt > > > Barry > > > > > 2) when removing some objects from a data structure that will be used data one currently needs to do > > > > XXXXDestroy(mystruct->something);CHKERRQ(ierr); mystruct->something = 0; > > > > instead of the cleaner XXXDestroy(&mystruct->something);CHKERRQ(ierr); > > > > True, but again I do not think the win is large. > > > > Matt > > > > -- > > 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 > > > > > -- > 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