__builtin_expect with other compilers

Jed Brown jed at 59A2.org
Mon Nov 30 09:48:02 CST 2009


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.sig>


More information about the petsc-dev mailing list