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