__builtin_expect with other compilers
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
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091130/9efda629/attachment.pgp
__builtin_expect with other compilers
On Mon, Nov 30, 2009 at 9:49 AM, Jed Brown jed at 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
__builtin_expect with other compilers
On Mon, 30 Nov 2009 11:07:40 -0300, Lisandro Dalcin dalcinl at 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. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091130/ac662570/attachment.pgp
-malloc_dump warnings
Jed, Looks like the following change is giving warnings with '-malloc_log' http://petsc.cs.iit.edu/petsc/petsc-dev/rev/4990e0f3 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
-malloc_dump warnings
On Mon, 30 Nov 2009 10:47:21 -0600 (CST), Satish Balay balay at 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/4990e0f3 Perhaps it can be reverted? Done, sorry about that. Jed -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091130/c8bbe14e/attachment.pgp
PETSC_ARCH variable -- PETSC_CONF
Lisandro has pointed out to me several times that the variable name PETSC_ARCH can be confusing; some people may think it is related to the architecture of the machine and don't understand that it is an arbitrary name that the user can make up. He suggested changing it to PETSC_CONF to be clearer. Should we change it? Use something else? Barry
PETSC_ARCH variable -- PETSC_CONF
I see the point, but this is one of the oldest parts of PETSc, and I am hesitant to change one arbitrary name to another without a more convincing reason. Matt On Mon, Nov 30, 2009 at 2:17 PM, Barry Smith bsmith at mcs.anl.gov wrote: Lisandro has pointed out to me several times that the variable name PETSC_ARCH can be confusing; some people may think it is related to the architecture of the machine and don't understand that it is an arbitrary name that the user can make up. He suggested changing it to PETSC_CONF to be clearer. Should we change it? Use something else? 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091130/bb928fec/attachment.html
PETSC_ARCH variable -- PETSC_CONF
I guess the argument is that on occasion in the future a certain number of people will misinterpret the meaning of PETSC_ARCH frustrating them and us; the number misinterpreting PETSC_CONF will be much smaller or zero saving people's time and energy. Barry On Nov 30, 2009, at 3:25 PM, Matthew Knepley wrote: I see the point, but this is one of the oldest parts of PETSc, and I am hesitant to change one arbitrary name to another without a more convincing reason. Matt On Mon, Nov 30, 2009 at 2:17 PM, Barry Smith bsmith at mcs.anl.gov wrote: Lisandro has pointed out to me several times that the variable name PETSC_ARCH can be confusing; some people may think it is related to the architecture of the machine and don't understand that it is an arbitrary name that the user can make up. He suggested changing it to PETSC_CONF to be clearer. Should we change it? Use something else? 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
PETSC_ARCH variable -- PETSC_CONF
On Mon, Nov 30, 2009 at 3:38 PM, Barry Smith bsmith at mcs.anl.gov wrote: I guess the argument is that on occasion in the future a certain number of people will misinterpret the meaning of PETSC_ARCH frustrating them and us; the number misinterpreting PETSC_CONF will be much smaller or zero saving people's time and energy. This will be far outweighed by the number of people complaining about such a change. I agree with them. Matt Barry On Nov 30, 2009, at 3:25 PM, Matthew Knepley wrote: I see the point, but this is one of the oldest parts of PETSc, and I am hesitant to change one arbitrary name to another without a more convincing reason. Matt On Mon, Nov 30, 2009 at 2:17 PM, Barry Smith bsmith at mcs.anl.gov wrote: Lisandro has pointed out to me several times that the variable name PETSC_ARCH can be confusing; some people may think it is related to the architecture of the machine and don't understand that it is an arbitrary name that the user can make up. He suggested changing it to PETSC_CONF to be clearer. Should we change it? Use something else? 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 -- 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091130/b548f1cb/attachment.html
PETSC_ARCH variable -- PETSC_CONF
Why not recognize both? It's fairly trivial to check for PETSC_CONF if PETSC_ARCH is undefined and internally define PETSC_ARCH using PETSC_CONF. Boyana -- Boyana Norris, Computer Scientist, Argonne National Laboratory norris at mcs.anl.gov, +1.630.252.7908, http://www.mcs.anl.gov/~norris/ On Nov 30, 2009, at 3:43 PM, Matthew Knepley wrote: On Mon, Nov 30, 2009 at 3:38 PM, Barry Smith bsmith at mcs.anl.gov wrote: I guess the argument is that on occasion in the future a certain number of people will misinterpret the meaning of PETSC_ARCH frustrating them and us; the number misinterpreting PETSC_CONF will be much smaller or zero saving people's time and energy. This will be far outweighed by the number of people complaining about such a change. I agree with them. Matt Barry On Nov 30, 2009, at 3:25 PM, Matthew Knepley wrote: I see the point, but this is one of the oldest parts of PETSc, and I am hesitant to change one arbitrary name to another without a more convincing reason. Matt On Mon, Nov 30, 2009 at 2:17 PM, Barry Smith bsmith at mcs.anl.gov wrote: Lisandro has pointed out to me several times that the variable name PETSC_ARCH can be confusing; some people may think it is related to the architecture of the machine and don't understand that it is an arbitrary name that the user can make up. He suggested changing it to PETSC_CONF to be clearer. Should we change it? Use something else? 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 -- 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091130/0fbc0351/attachment.html
PETSC_ARCH variable -- PETSC_CONF
On Nov 30, 2009, at 3:51 PM, Boyana Norris wrote: Why not recognize both? It's fairly trivial to check for PETSC_CONF if PETSC_ARCH is undefined and internally define PETSC_ARCH using PETSC_CONF. This is a make variable. I am not sure that it is trivial to check if a variable is set and use something else otherwise in a tidy way in make. Plus I had the idea of having two variables that mean the same thing. Barry Boyana -- Boyana Norris, Computer Scientist, Argonne National Laboratory norris at mcs.anl.gov, +1.630.252.7908, http://www.mcs.anl.gov/~norris/ On Nov 30, 2009, at 3:43 PM, Matthew Knepley wrote: On Mon, Nov 30, 2009 at 3:38 PM, Barry Smith bsmith at mcs.anl.gov wrote: I guess the argument is that on occasion in the future a certain number of people will misinterpret the meaning of PETSC_ARCH frustrating them and us; the number misinterpreting PETSC_CONF will be much smaller or zero saving people's time and energy. This will be far outweighed by the number of people complaining about such a change. I agree with them. Matt Barry On Nov 30, 2009, at 3:25 PM, Matthew Knepley wrote: I see the point, but this is one of the oldest parts of PETSc, and I am hesitant to change one arbitrary name to another without a more convincing reason. Matt On Mon, Nov 30, 2009 at 2:17 PM, Barry Smith bsmith at mcs.anl.gov wrote: Lisandro has pointed out to me several times that the variable name PETSC_ARCH can be confusing; some people may think it is related to the architecture of the machine and don't understand that it is an arbitrary name that the user can make up. He suggested changing it to PETSC_CONF to be clearer. Should we change it? Use something else? 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 -- 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
PETSC_ARCH variable -- PETSC_CONF
On Nov 30, 2009, at 3:59 PM, Barry Smith wrote: On Nov 30, 2009, at 3:51 PM, Boyana Norris wrote: Why not recognize both? It's fairly trivial to check for PETSC_CONF if PETSC_ARCH is undefined and internally define PETSC_ARCH using PETSC_CONF. This is a make variable. I am not sure that it is trivial to check if a variable is set and use something else otherwise in a tidy way in make. Plus I had the idea of having two variables that mean the same thing. There are a couple of different ways, e.g., one is ifndef PETSC_ARCH ifdef PETSC_CONF PETSC_ARCH=$(PETSC_CONF) else $(error Make sure the PETSC_CONF environment variable is defined before running make.) endif endif This is for GNU make, which is pretty widely available, and may have to be adjusted for ancient systems. Boyana Barry Boyana -- Boyana Norris, Computer Scientist, Argonne National Laboratory norris at mcs.anl.gov, +1.630.252.7908, http://www.mcs.anl.gov/~norris/ On Nov 30, 2009, at 3:43 PM, Matthew Knepley wrote: On Mon, Nov 30, 2009 at 3:38 PM, Barry Smith bsmith at mcs.anl.gov wrote: I guess the argument is that on occasion in the future a certain number of people will misinterpret the meaning of PETSC_ARCH frustrating them and us; the number misinterpreting PETSC_CONF will be much smaller or zero saving people's time and energy. This will be far outweighed by the number of people complaining about such a change. I agree with them. Matt Barry On Nov 30, 2009, at 3:25 PM, Matthew Knepley wrote: I see the point, but this is one of the oldest parts of PETSc, and I am hesitant to change one arbitrary name to another without a more convincing reason. Matt On Mon, Nov 30, 2009 at 2:17 PM, Barry Smith bsmith at mcs.anl.gov wrote: Lisandro has pointed out to me several times that the variable name PETSC_ARCH can be confusing; some people may think it is related to the architecture of the machine and don't understand that it is an arbitrary name that the user can make up. He suggested changing it to PETSC_CONF to be clearer. Should we change it? Use something else? 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 -- 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
PETSC_ARCH variable -- PETSC_CONF
Boyana, We are going to stop using make before we ever start using GNU make features :-) Barry On Nov 30, 2009, at 4:23 PM, Boyana Norris wrote: On Nov 30, 2009, at 3:59 PM, Barry Smith wrote: On Nov 30, 2009, at 3:51 PM, Boyana Norris wrote: Why not recognize both? It's fairly trivial to check for PETSC_CONF if PETSC_ARCH is undefined and internally define PETSC_ARCH using PETSC_CONF. This is a make variable. I am not sure that it is trivial to check if a variable is set and use something else otherwise in a tidy way in make. Plus I had the idea of having two variables that mean the same thing. There are a couple of different ways, e.g., one is ifndef PETSC_ARCH ifdef PETSC_CONF PETSC_ARCH=$(PETSC_CONF) else $(error Make sure the PETSC_CONF environment variable is defined before running make.) endif endif This is for GNU make, which is pretty widely available, and may have to be adjusted for ancient systems. Boyana Barry Boyana -- Boyana Norris, Computer Scientist, Argonne National Laboratory norris at mcs.anl.gov, +1.630.252.7908, http://www.mcs.anl.gov/~norris/ On Nov 30, 2009, at 3:43 PM, Matthew Knepley wrote: On Mon, Nov 30, 2009 at 3:38 PM, Barry Smith bsmith at mcs.anl.gov wrote: I guess the argument is that on occasion in the future a certain number of people will misinterpret the meaning of PETSC_ARCH frustrating them and us; the number misinterpreting PETSC_CONF will be much smaller or zero saving people's time and energy. This will be far outweighed by the number of people complaining about such a change. I agree with them. Matt Barry On Nov 30, 2009, at 3:25 PM, Matthew Knepley wrote: I see the point, but this is one of the oldest parts of PETSc, and I am hesitant to change one arbitrary name to another without a more convincing reason. Matt On Mon, Nov 30, 2009 at 2:17 PM, Barry Smith bsmith at mcs.anl.gov wrote: Lisandro has pointed out to me several times that the variable name PETSC_ARCH can be confusing; some people may think it is related to the architecture of the machine and don't understand that it is an arbitrary name that the user can make up. He suggested changing it to PETSC_CONF to be clearer. Should we change it? Use something else? 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 -- 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
PETSC_ARCH variable -- PETSC_CONF
Actually GNU make features are the only reason I continue to touch make -- without them I would not use it for anything. Boyana -- Boyana Norris, Computer Scientist, Argonne National Laboratory norris at mcs.anl.gov, +1.630.252.7908, http://www.mcs.anl.gov/~norris/ On Nov 30, 2009, at 4:29 PM, Barry Smith wrote: Boyana, We are going to stop using make before we ever start using GNU make features :-) Barry On Nov 30, 2009, at 4:23 PM, Boyana Norris wrote: On Nov 30, 2009, at 3:59 PM, Barry Smith wrote: On Nov 30, 2009, at 3:51 PM, Boyana Norris wrote: Why not recognize both? It's fairly trivial to check for PETSC_CONF if PETSC_ARCH is undefined and internally define PETSC_ARCH using PETSC_CONF. This is a make variable. I am not sure that it is trivial to check if a variable is set and use something else otherwise in a tidy way in make. Plus I had the idea of having two variables that mean the same thing. There are a couple of different ways, e.g., one is ifndef PETSC_ARCH ifdef PETSC_CONF PETSC_ARCH=$(PETSC_CONF) else $(error Make sure the PETSC_CONF environment variable is defined before running make.) endif endif This is for GNU make, which is pretty widely available, and may have to be adjusted for ancient systems. Boyana Barry Boyana -- Boyana Norris, Computer Scientist, Argonne National Laboratory norris at mcs.anl.gov, +1.630.252.7908, http://www.mcs.anl.gov/ ~norris/ On Nov 30, 2009, at 3:43 PM, Matthew Knepley wrote: On Mon, Nov 30, 2009 at 3:38 PM, Barry Smith bsmith at mcs.anl.gov wrote: I guess the argument is that on occasion in the future a certain number of people will misinterpret the meaning of PETSC_ARCH frustrating them and us; the number misinterpreting PETSC_CONF will be much smaller or zero saving people's time and energy. This will be far outweighed by the number of people complaining about such a change. I agree with them. Matt Barry On Nov 30, 2009, at 3:25 PM, Matthew Knepley wrote: I see the point, but this is one of the oldest parts of PETSc, and I am hesitant to change one arbitrary name to another without a more convincing reason. Matt On Mon, Nov 30, 2009 at 2:17 PM, Barry Smith bsmith at mcs.anl.gov wrote: Lisandro has pointed out to me several times that the variable name PETSC_ARCH can be confusing; some people may think it is related to the architecture of the machine and don't understand that it is an arbitrary name that the user can make up. He suggested changing it to PETSC_CONF to be clearer. Should we change it? Use something else? 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 -- 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
PETSC_ARCH variable -- PETSC_CONF
The problem is that we cannot demand that every PETSc user install a decent version of gnu make. Some systems have their own strange make and getting users to install gnu make and get PETSc to use it is asking too much. Barry On Nov 30, 2009, at 4:38 PM, Boyana Norris wrote: Actually GNU make features are the only reason I continue to touch make -- without them I would not use it for anything. Boyana -- Boyana Norris, Computer Scientist, Argonne National Laboratory norris at mcs.anl.gov, +1.630.252.7908, http://www.mcs.anl.gov/~norris/ On Nov 30, 2009, at 4:29 PM, Barry Smith wrote: Boyana, We are going to stop using make before we ever start using GNU make features :-) Barry On Nov 30, 2009, at 4:23 PM, Boyana Norris wrote: On Nov 30, 2009, at 3:59 PM, Barry Smith wrote: On Nov 30, 2009, at 3:51 PM, Boyana Norris wrote: Why not recognize both? It's fairly trivial to check for PETSC_CONF if PETSC_ARCH is undefined and internally define PETSC_ARCH using PETSC_CONF. This is a make variable. I am not sure that it is trivial to check if a variable is set and use something else otherwise in a tidy way in make. Plus I had the idea of having two variables that mean the same thing. There are a couple of different ways, e.g., one is ifndef PETSC_ARCH ifdef PETSC_CONF PETSC_ARCH=$(PETSC_CONF) else $(error Make sure the PETSC_CONF environment variable is defined before running make.) endif endif This is for GNU make, which is pretty widely available, and may have to be adjusted for ancient systems. Boyana Barry Boyana -- Boyana Norris, Computer Scientist, Argonne National Laboratory norris at mcs.anl.gov, +1.630.252.7908, http://www.mcs.anl.gov/~norris/ On Nov 30, 2009, at 3:43 PM, Matthew Knepley wrote: On Mon, Nov 30, 2009 at 3:38 PM, Barry Smith bsmith at mcs.anl.gov wrote: I guess the argument is that on occasion in the future a certain number of people will misinterpret the meaning of PETSC_ARCH frustrating them and us; the number misinterpreting PETSC_CONF will be much smaller or zero saving people's time and energy. This will be far outweighed by the number of people complaining about such a change. I agree with them. Matt Barry On Nov 30, 2009, at 3:25 PM, Matthew Knepley wrote: I see the point, but this is one of the oldest parts of PETSc, and I am hesitant to change one arbitrary name to another without a more convincing reason. Matt On Mon, Nov 30, 2009 at 2:17 PM, Barry Smith bsmith at mcs.anl.gov wrote: Lisandro has pointed out to me several times that the variable name PETSC_ARCH can be confusing; some people may think it is related to the architecture of the machine and don't understand that it is an arbitrary name that the user can make up. He suggested changing it to PETSC_CONF to be clearer. Should we change it? Use something else? 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 -- 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
