On Tue, Apr 7, 2009 at 9:51 PM, Ahmed El Zein <span dir="ltr"><<a href="mailto:ahmed@azein.com">ahmed@azein.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Tue, 2009-04-07 at 10:39 -0500, Matthew Knepley wrote:<br>
> On Tue, Apr 7, 2009 at 9:07 AM, Stephen Ball<br>
> <<a href="mailto:Stephen.R.Ball@awe.co.uk">Stephen.R.Ball@awe.co.uk</a>> wrote:<br>
> Hi<br>
><br>
> We are keen to start investigating whether or not PETSc is<br>
> suitable for<br>
> acceleration on novel architectures like GPUs, Cell<br>
> processors, etc.<br>
><br>
> I would very much like to get your opinions on this.<br>
><br>
> Do you think such an endeavour is at all feasible with PETSc?<br>
> If so,<br>
> what areas of PETSc do you think our efforts would best be<br>
> spent?<br>
><br>
> Should we for example focus on matrix operations, or on<br>
> specific<br>
> preconditioners or solvers? Where would be a good place to<br>
> start?<br>
><br>
> Can you suggest some specific routines/functions in PETSc that<br>
> are<br>
> potential candidates for acceleration?<br>
><br>
> We are actually already working on this, and I plan on having a<br>
> PETSc-GPU<br>
> come out at the end of the year.<br>
<br>
</div>What language are you using? I would have thought that OpenCL would be<br>
the best solution. Maybe even rewriting the whole of PETSc in OpenCL,<br>
targeting both multicore CPUs and a few novel architectures at the same<br>
time. AMD and NVIDIA are both going to support OpenCL for their GPUs and<br>
I believe that it will be supported on Intel's larrabee and the Cell<br>
processor.</blockquote><div><br>That is probably a mistake. OpenCL is not mature and only a few operations in<br>PETSc would really benefit.<br><br> Matt<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<font color="#888888"><br>
Ahmed<br>
</font><div><div></div><div class="h5"><br>
> Therefore, I suggest working on PCs that<br>
> are specific to your problems. People are already doing good work on<br>
> sparse<br>
> matrices in general, and solvers will see no speedup at all, since<br>
> they are all<br>
> logic.<br>
><br>
> Matt<br>
><br>
><br>
> Regards<br>
><br>
> Stephen R. Ball<br>
> Advanced Technologies<br>
> HPC<br>
> DRAS<br>
> Rm: G17<br>
> Bldg: E1.1<br>
> AWE(A)<br>
> Aldermaston<br>
> Reading<br>
> Berkshire<br>
> ENGLAND<br>
> RG7 4PR<br>
> Tel: +44 (0)118 982 4528<br>
> e-mail: <a href="mailto:stephen.r.ball@awe.co.uk">stephen.r.ball@awe.co.uk</a><br>
><br>
> This e-mail and any attachments may contain confidential and<br>
> privileged information. If you are not the intended recipient,<br>
> please notify the sender immediately by return e-mail, delete<br>
> this<br>
> e-mail and destroy any copies. Any dissemination or use of<br>
> this<br>
> information by a person other than the intended recipient is<br>
> unauthorized and may be illegal.<br>
><br>
><br>
><br>
> --<br>
> What most experimenters take for granted before they begin their<br>
> experiments is infinitely more interesting than any results to which<br>
> their experiments lead.<br>
> -- Norbert Wiener<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>