<div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 12, 2012 at 10:46 PM, Karl Rupp <span dir="ltr"><<a href="mailto:rupp@mcs.anl.gov" target="_blank">rupp@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">

Hey,<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
        Then add on top of this the fact that you could simply recompile<br>
        PETSc, run it natively on the card, and still run it on your<br>
        CPU's as MPMD.<br>
<br>
<br>
    This is a good way to get terrible performance.<br>
<br>
<br>
Why?  Decompose your domain to take into account the imbalance in<br>
computational power.  The link between the card and the CPU is going to<br>
be faster than going to another node.<br>
</blockquote>
<br></div>
I fully second Jed. Computational scientists are already fighting with getting scalable performance on a 'standard' multi-core architecture, so I doubt that one can really obtain a gain on an accelerator-architecture for any real-world application just be recompilation of  existing code. Also, add the extra issue of PCI-Express latency.<br>

</blockquote><div><br>Two key points here:<br><br>1) the application will have to be threaded to get good performance on the Xeon Phi.  I know that PETSc is moving in this direction. My thought was that you would have 1 MPI process on the card and 1 on each CPU and use threads.<br>

<br>2)  The recompilation is needed to run in "Native mode".  This is not an offloaded computation in the GPU sense.  The entire program runs on the card.  All the memory is local.  You run one binary on the card, a different binary on the CPU.  The only thing that has to cross the bus is MPI communication, which should be faster than even the fastest network cards because it only has to cross the bus.<br>

<br><br>John<br><br></div></div></div>