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>
