November 2009 - petsc-dev - mailman3.cels.anl.gov

Re: -malloc_dump warnings
by Jed Brown 30 Nov '09

30 Nov '09

On Mon, 30 Nov 2009 10:47:21 -0600 (CST), Satish Balay <balay(a)mcs.anl.gov> wrote: > Jed, > > Looks like the following change is giving warnings with '-malloc_log' > > http://petsc.cs.iit.edu/petsc/petsc-dev/rev/4990e0f34444 > > Perhaps it can be reverted? Done, sorry about that. Jed

1 0

-malloc_dump warnings
by Satish Balay 30 Nov '09

30 Nov '09

Jed, Looks like the following change is giving warnings with '-malloc_log' http://petsc.cs.iit.edu/petsc/petsc-dev/rev/4990e0f34444 Perhaps it can be reverted? thanks, Satish ------ asterix:/home/balay/tmp/spetsc/src/ksp/ksp/examples/tutorials>./ex2 -malloc_dump Norm of error 0.000156044 iterations 6 WARNING! There are options you set that were not used! WARNING! could be spelling mistake, etc! Option left: name:-malloc_dump no value asterix:/home/balay/tmp/spetsc/src/ksp/ksp/examples/tutorials>

1 0

Re: __builtin_expect with other compilers
by Jed Brown 30 Nov '09

30 Nov '09

On Mon, 30 Nov 2009 11:07:40 -0300, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > Indeed. Cython (used in petsc4py) uses these definitions everywhere. I think they are just clutter unless it's a "hot" conditional or used so pervasively that it changes code size (CHKERRQ). But they are certainly valuable when used appropriately. > IIRC, Intel compilers do support __builtin_expect, too. The Sun compilers do as well so I added a configure check, created PetscLikely/PetscUnlikely macros, and put this into CHKERRQ. http://petsc.cs.iit.edu/petsc/petsc-dev/rev/51e933be84ca > A big +1 from my side. This will alleviate (at least with gcc and icc) > some Matt's concerns about miss-predictions we discussed long ago. At > that time, I was asking for optimized builds Note that it requires --with-errorchecking=0 which is not a normal part of an optimized build. > to "#define CHKERRQ(ierr) if (ierr) return ierr;" instead of empty. So with error handling, we get call SomePetscFunction test eax,eax je ErrorPathForFirstLine ;; shuffle registers to call the next function ;; ... call AnotherFunction test eax,eax je ErrorPathForSecondLine With no error checking, the test, je stuff would be completely gone, i.e. call SomePetscFunction ;; shuffle registers to call the next function ;; ... call AnotherFunction test eax,eax je ErrorPathForSecondLine which actually makes the non-error path smaller. With your suggestion, the non-error path will look exactly as above (the jump address would be constant). The error path would usually be on the same page as the rest of the function so it would have to come to L2 [1], but it should almost never make it to L1I so I would expect there is no measurable difference between calling PetscError and your simple return. Without a benchmark showing differently, I wouldn't be in favor of supporting that option. Jed [1] -freorder-blocks-and-partition might be able to keep it out of L2 as well.

1 0

Re: __builtin_expect with other compilers
by Lisandro Dalcin 30 Nov '09

30 Nov '09

On Mon, Nov 30, 2009 at 9:49 AM, Jed Brown <jed(a)59a2.org> wrote: > I noticed that GCC mispredicts the conditional in CHKERRQ. At high > optimization levels it still relocates most of the PetscError call, but > the non-error path is cleaner with > > #define CHKERRQ(n) if (UNLIKELY(n)) {return PetscError(__LINE__,__FUNCT__,__FILE__,__SDIR__,n,0," ");} > I wanted to comment on this from long time ago, but never got time to investigate > where the following definitions are typical > > #define UNLIKELY(c) __builtin_expect(!!(c),0) > #define LIKELY(c) __builtin_expect(!!(c),1) > Indeed. Cython (used in petsc4py) uses these definitions everywhere. > > I'm not familiar with the analogues for other compilers. > IIRC, Intel compilers do support __builtin_expect, too. > I don't > suggest cluttering the code with such hints, but just putting it in > CHKERRQ would decrease code size for the non-error path which seems like > a good thing. > A big +1 from my side. This will alleviate (at least with gcc and icc) some Matt's concerns about miss-predictions we discussed long ago. At that time, I was asking for optimized builds to "#define CHKERRQ(ierr) if (ierr) return ierr;" instead of empty. -- 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

__builtin_expect with other compilers
by Jed Brown 30 Nov '09

30 Nov '09

I noticed that GCC mispredicts the conditional in CHKERRQ. At high optimization levels it still relocates most of the PetscError call, but the non-error path is cleaner with #define CHKERRQ(n) if (UNLIKELY(n)) {return PetscError(__LINE__,__FUNCT__,__FILE__,__SDIR__,n,0," ");} where the following definitions are typical #define UNLIKELY(c) __builtin_expect(!!(c),0) #define LIKELY(c) __builtin_expect(!!(c),1) I'm not familiar with the analogues for other compilers. I don't suggest cluttering the code with such hints, but just putting it in CHKERRQ would decrease code size for the non-error path which seems like a good thing. Jed

1 0

Re: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Lisandro Dalcin 29 Nov '09

29 Nov '09

On Sun, Nov 29, 2009 at 7:55 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > I have made some changes so that when using the --prefix option there is no > need to set PETSC_DIR or PETSC_ARCH. > > ./configure --prefix=... other options > make > make install > Great! Many thanks, Barry! Jose: Any chance you can implement something similar in SLEPc? -- 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: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Barry Smith 29 Nov '09

29 Nov '09

I have made some changes so that when using the --prefix option there is no need to set PETSC_DIR or PETSC_ARCH. ./configure --prefix=... other options make make install Barry On Nov 27, 2009, at 5:47 PM, Satish Balay wrote: > On Fri, 27 Nov 2009, Barry Smith wrote: > > >> How does the gnu/autoconf world handle this. If you have two gnu/ >> autoconf >> installed packages how can you tell they are compatible? You should >> use the >> same type of mechanism they use. (what?, they don't have such a >> mechanism? >> Well then that is a limitation of the --prefix model and you have >> to live with >> that). > > The issue is not what the prefix model dictates. The issue is: do > slepc/petsc4py support both modes of install similar to PETSc. If not > why does PETSc need PETSC_ARCH for a prefix install? [if we are so > pure with supporting gnu/autoconf model?]. > > Satish >

1 0

Re: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Barry Smith 27 Nov '09

27 Nov '09

On Nov 27, 2009, at 6:04 PM, Lisandro Dalcin wrote: > On Fri, Nov 27, 2009 at 8:52 PM, Satish Balay <balay(a)mcs.anl.gov> > wrote: >> On Fri, 27 Nov 2009, Satish Balay wrote: >> > > This tread got long enough. Let's stop here, please. All us have more > important matters to spend our time. I think I'll end-up requiring > users to prefix-installs for both PETSc and SLEPc, or non-prefix also > for both, but never a mix. Sounds reasonable to me. Having one with prefix and one without is perverse. Barry > > -- > 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: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Lisandro Dalcin 27 Nov '09

27 Nov '09

On Fri, Nov 27, 2009 at 8:52 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > On Fri, 27 Nov 2009, Satish Balay wrote: > >> On Fri, 27 Nov 2009, Barry Smith wrote: >> >> >> > How does the gnu/autoconf world handle this. If you have two gnu/autoconf >> > installed packages how can you tell they are compatible? You should use the >> > same type of mechanism they use. (what?, they don't have such a mechanism? >> > Well then that is a limitation of the --prefix model and you have to live with >> > that). >> >> The issue is not what the prefix model dictates. The issue is: do >> slepc/petsc4py support both modes of install similar to PETSc. If not >> why does PETSc need PETSC_ARCH for a prefix install? [if we are so >> pure with supporting gnu/autoconf model?]. > > I read the comment slightly out of context - please ignore.. [now I > see you are refering to the "unique-identifier" as a sanity check > issue] > Indeed. Right now I've already pushed fixes for the changes in petsc-dev. Currently I can suport a prefix-PETSc+prefix-SLEPc, or non-prefix-PETSc+non-prefix-SLEPc. The later is a non-issue, as PETSC_ARCH more or less disambiguate incompatible builds and moreover let runtime-selection of what variant to use (think of hacking Python import path, though I did something a safer). However, mixes schemes are harder to deal. You know how easy is for end users (and the many naive sysadmins) out there to make nasty mixups of incompatible stuff. I want to protect from that, because I do not want to waste my time with mails arriving at my inbox saying "hey Lisandro, I've installed petsc4py and slepc4py, but i get Segmentation fault, do you know what could be going on?" This tread got long enough. Let's stop here, please. All us have more important matters to spend our time. I think I'll end-up requiring users to prefix-installs for both PETSc and SLEPc, or non-prefix also for both, but never a mix. -- 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: Why did you removed PETSC_ARCH_NAME variable in makefiles?
by Satish Balay 27 Nov '09

27 Nov '09

On Fri, 27 Nov 2009, Satish Balay wrote: > On Fri, 27 Nov 2009, Barry Smith wrote: > > > > How does the gnu/autoconf world handle this. If you have two gnu/autoconf > > installed packages how can you tell they are compatible? You should use the > > same type of mechanism they use. (what?, they don't have such a mechanism? > > Well then that is a limitation of the --prefix model and you have to live with > > that). > > The issue is not what the prefix model dictates. The issue is: do > slepc/petsc4py support both modes of install similar to PETSc. If not > why does PETSc need PETSC_ARCH for a prefix install? [if we are so > pure with supporting gnu/autoconf model?]. I read the comment slightly out of context - please ignore.. [now I see you are refering to the "unique-identifier" as a sanity check issue] satish

1 0