[petsc-users] [petsc-maint #78983] Re: MPI v. Pthreads ?

[John Chludzinski]

You mentioned: "pthread based Vec and Mat class that lives inside the PETSc
MPI world".  Is this pthreads *in lieu of* MPI or is it pthreads *in
addition to* MPI?

---John

On Sun, Jul 10, 2011 at 1:19 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> On Jul 9, 2011, at 11:57 PM, John Chludzinski wrote:
>
> > 1) Since Linux now (as of the 2.6 kernel) supports a 1-to-1
> > association/mapping between pthreads (user threads) and kthreads (kernel
> > threads), plus the new process scheduler, this makes pthreads much more
> > efficient/useful for MIMD parallelism.  I assume this makes a
> thread-based
> > solution (PETSc) more attractive?  When PETSc was first conceived, this
> was
> > not the case.
> >
> > 2) Since threads can share data (variables), wouldn't there be less of a
> > need to send/receive data than using MPI, which simply spawns separate
> > disjoint processes?
> >
> > 3) "  Vec and Mat class"?  I hope you're sticking with C (v. C++)?  I've
> > used G++ version 4.3.4 and version 4.5.2 and got different answers with
> the
> > exact same source.  I have used Visual C++ (2008) and got different
> answers
> > than G++ 4.6.1 - again the same source.  C99 seems to give consistent
> > results across compilers/platforms and is simpler to boot.
>
>     We call them "classes" because they provide encapsulation,
> polymorphism, and inheritance but yes it will remain C.
>
>   Barry
>
> >
> > ---John
> >
> >
> > On Sat, Jul 9, 2011 at 11:41 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >
> >>
> >>  We have started a pthread based Vec and Mat class that lives inside the
> >> PETSc MPI world. We will be pushing it into the petsc-dev repository in
> the
> >> next could of weeks.
> >>
> >> Notes:
> >>
> >> 1) Since all the numerical computations take place in the Vec and Mat
> class
> >> those are the ones that need to use pthreads underneath, the other
> classes
> >> like KSP do not.
> >> 2) A group in England has developed a OpenMP based Vec and Mat class in
> the
> >> same vain as our pthread version; I've been trying without success to
> get it
> >> also into petsc-dev, hopefully I'll eventually charm them into it.
> >> 3) Since sparse iterative solvers are very much memory bandwidth limited
> >> (the time to solve is determined by the speed of the memory, not the
> CPUs)
> >> there is only some much one can do to improve performance by throwing
> more
> >> cores (threads) at the problem. For example most cheap desktop systems
> do
> >> not have enough memory bandwidth to support even two cores doing the
> >> iterative solver so adding pthreads will only matter on certain (more
> >> expensive) systems and is not a "cure all".  See
> >> http://www.mcs.anl.gov/petsc/petsc-as/documentation/faq.html#computers
> >>
> >>
> >>   Barry
> >>
> >>
> >> On Jul 9, 2011, at 10:31 PM, John Chludzinski wrote:
> >>
> >>> Have you guys considered a pthread based implementation of PETSc/SLEPc.
> >>> Have you investigated the use of pthreads?  ---John
> >>>
> >>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20110710/d582cd03/attachment.htm>