[petsc-users] MPI v. Pthreads ?

[John Chludzinski]

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.

---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/597df516/attachment.htm>