On 28/02/2012 20:18, Jed Brown wrote: ...
> I prefer inlining the loop bounds into macro/function calls at point of > use, rather than relying on magic names from a macro definition, but I'm > not completely wedded to the idea. > > > Not a big deal, we could optimize either variant. Moving forward, I've done a bunch of this macroisation, which makes the code more PETSc-like. As you point out it's probably unwise to call omp_get_num_threads() on every loop iteration, so I went for the magic names in the end. A typical simple loop now looks like: VecOMPParallelBegin(xin, private(i) shared(x)); for (i=__start; i<__end;i++) x[i] = work(x[i]); VecOMPParallelEnd(); In the --without-openmp case, this transforms into: do { PetscInt __start = 0, __end = xin->map->n; for ...; } while (0); Rather than adding an nthreads slot to vectors, I put it in the generic PetscObject struct -- we're threading matrices too. I don't know how to write the correct tests for configure to probe for the existance of _Pragma, so that's still missing. Cheers, Lawrence -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.