#if (PETSC_SIZEOF_LONG_LONG == 8) typedef long long Petsc64bitInt; #elif defined(PETSC_HAVE___INT64) typedef __int64 Petsc64bitInt; #else typedef unknown64bit Petsc64bitInt #endif
I assume all machines support one or the other of these ? Should we introduce an unsigned version of this Petsc64bitUInt, for these type of things? Barry On Sep 8, 2013, at 1:44 PM, Jed Brown <[email protected]> wrote: > Barry Smith <[email protected]> writes: > >>> An alternative would be to add a scalar parameter to MatMultAdd. >> >> MatResidual() is an important enough case to merit its own >> method. The odd ball scalar parameter that is not 1 or -1 is so >> extremely rare as to lead to confusion instead of useful >> generality. > > Fine, but implementations might want to unify the add and subtract > kernels because it's half the code. > >>> Perhaps PetscObjects should get a 64-bit unique ID assigned by a global >> >> Why 64 bit? Surely we will never have more than 2 billion objects created? > > It's not the number of objects in scope, but the cumulative number of > objects. Some simulations take billions of time steps. You might say > they should ensure that everything is reused over that period, but it's > hard to guarantee and this failure mode is just not worth allowing into > the realm of possibility. If it were up to me, I would also make the > State integer 64-bit. (You don't want to hand a Vec off to a stochastic > optimizer that does a million forward and adjoint simulations, each with > 1000 time steps, and have a possibility of reusing some stale cache > once you get the solution vector back.) > >>> counter, or even a slightly longer hash of information that should never >>> repeat. Caching the pointer leaves the ABA problem. >> >> We currently have >> h->id = idcnt++; >> in PetscHeaderCreate_Private(). >> >> The id is not consistent across processes for a given object but I >> don't think that matters. Why can't we just stash this value? I >> think this value plus the Vec/Mat state uniquely define the values >> in the Vec/Mat. > > I forgot about that, but I think we should make it 64-bit. > >> There is a possibility of some processes having the same state and >> others different ones and thus errors due to different functions being >> used; for example if one process called VecGetArrayWrite() but another >> one didn't. This is perverse so ….? > > VecGetArray is documented to be logically collective. There are some, > ahem, C++ libraries downstream that are dedicated to abusing the > interface with unstructured operator overloading.
