Hello,
Recently migrated from Fedora34 to Fedora36, using PETSc I have some lag during
the PetscInitialize, which
disappeared if I run again immediately the binary. But after few seconds, the
lag happens again (see below).
I suspected MPICH 4.0.2 on Fedora36, but a small reproducer indicated
My guess is it related to the file system, possible caching executables
and/or shared libraries. I can't see any thing in PETSc that could possible
affect the start up speed based on the last time it was run.
You can run with -info to see how quickly the output comes when you start the
ru
On Wed, Jul 27, 2022 at 9:22 AM LEDAC Pierre wrote:
> Hello,
>
>
> Recently migrated from Fedora34 to Fedora36, using PETSc I have some lag
> during the PetscInitialize, which
>
> disappeared if I run again immediately the binary. But after few seconds,
> the lag happens again (see below).
>
>
>
FWIW, vendors have poured a lot of effort into making C++ the industry
standard for HPC, and it will remain that way for a very long time.
Switching PETSc to a non-C/C++/Python/Fortran language today while still
enabling GPU/accelerated computing could get ugly from a code
implementation perspectiv
Stan is less than 10 years old, has over 100,000 users and created their own
language (that gets compiled to C++ code). Their community, like some
optimization sub-communities) have a history of creating their own languages,
unlike numerical linear algebra that didn't need to because Fortran
I'm seeing this behavior on a laptop - but not desktop [both F36] (with both
mpich and openmpi buids)
laptop/mpich
balay@p1 /home/balay/petsc/src/ksp/ksp/tests (main =)
$ sleep 30; time ./ex39; time ./ex39
real0m1.709s
user0m0.079s
sys 0m0.042s
real0m0.116s
user0m0
Ok thanks all, so with Satish test, we know it is MPI_Init call from
PetscInitialize.
Probably, as Matt said, something related to gethostbyname() ...
I will do some other test, contact MPICH support and will report any workaround,
Thanks again for your reactivity !
Pierre LEDAC
Commissari
"sleep 30; strace ./ex39" shows an extra pause while reading the following file
(on my laptop):
balay@p1 /home/balay
$ sleep 10; time cat /sys/bus/pci/devices/:00:01.0/config; time cat
/sys/bus/pci/devices/:00:01.0/config
�00���
real0m1.271s
user0m0.000s
sys 0m0.
On Wed, 27 Jul 2022, Satish Balay via petsc-dev wrote:
> Maybe should try without hwloc...
So this helps! i.e build with:
$ ./configure --with-debugging=0 --download-mpich --with-hwloc=0 && make
>>>
balay@p1 /home/balay/petsc/src/ksp/ksp/tests (main =)
$ sleep 30; time ./ex39; time ./ex39
real
I expect PETSc will have some C++ (CUDA/HIP/SYCL) code for the foreseeable
future, but that doesn't mean the primary implementation language needs to be
C++, nor that it needs to bleed directly into a public interface. Much of the
value in PETSc is higher level than GPU numerical kernels.
One i
The API for PETSc is (by design) highly object-oriented; the data
encapsulation is helpful and rarely gets in the way of performance. The object
oriented nature makes it easier to be supported by multiple languages even when
one does not utilize the idiomatic features for object-oriented code
PETSc has never used fine grain OO, like per row of a matrix or per element in
a mesh (compare DMPlex with libMesh). But languages have idioms related to
features like iterators, high-order functions/closures, traits, error
handling/nullability, and multimethods. You can usually make a naive int
> On Jul 27, 2022, at 5:47 PM, Jed Brown wrote:
>
> PETSc has never used fine grain OO, like per row of a matrix or per element
> in a mesh (compare DMPlex with libMesh).
Yes, because even in 1994, we knew that was a dead-end for performance and
unnecessary as well :-)
> But languages hav
Hello,
Running my example using VECMPICUDA for VecSetType(), and MATMPIAIJCUSP for
MatSetType(), I have the profiling results as shown below. It is seen that
MatSOR() has %F of GPU, only has GpuToCpu count and size. Is it correct that
PETSc currently does not have MatSOR implemented on GPU? It
Unfortunately, MatSOR is a really bad operation for GPUs. We can make it use
sparse triangular primitives from cuSPARSE, but those run on GPU at about 20x
slower than MatMult with the same sparse matrix. So unless MatSOR reduces
iteration count by 20x compared to your next-best preconditioning o
This seems like an opportune moment to flag that we’re proposing a sprint at
some point in 2023 to document petsc4py. Right now there are no docstrings in
petsc4py, which means users have to infer what the corresponding C function
name is and read the docstring for that, then understand enough
There are multicolor versions of SOR that theoretically offer good
parallelism on GPUs but at the cost of multiple phases and slower convergence
rates. Unless someone already has one coded for CUDA or Kokkos it would take a
good amount of code to produce one that offers (but does not necessa
17 matches
Mail list logo
