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.<br>
<div><br></div><div>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?</div><div><br></div><div>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.</div>
<div><br></div><font color="#888888"><div>---John</div></font><div><div><div><br></div><div><br></div><div class="gmail_quote">On Sat, Jul 9, 2011 at 11:41 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
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.<br>
<br>
Notes:<br>
<br>
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.<br>
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.<br>
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 <a href="http://www.mcs.anl.gov/petsc/petsc-as/documentation/faq.html#computers" target="_blank">http://www.mcs.anl.gov/petsc/petsc-as/documentation/faq.html#computers</a><br>
<font color="#888888"><br>
<br>
Barry<br>
</font><div><div><br>
<br>
On Jul 9, 2011, at 10:31 PM, John Chludzinski wrote:<br>
<br>
> Have you guys considered a pthread based implementation of PETSc/SLEPc.<br>
> Have you investigated the use of pthreads? ---John<br>
><br>
<br>
</div></div></blockquote></div><br>
</div></div><br>
<br>