On Wed, Apr 8, 2009 at 10:29 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><div></div><div class="h5">On Wed, 2009-04-08 at 10:52 -0500, Matthew Knepley wrote:<br>
> On Tue, Apr 7, 2009 at 9:51 PM, Ahmed El Zein <<a href="mailto:ahmed@azein.com">ahmed@azein.com</a>> wrote:<br>
>         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<br>
>         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<br>
>         with PETSc?<br>
>         >         If so,<br>
>         >         what areas of PETSc do you think our efforts would<br>
>         best be<br>
>         >         spent?<br>
>         ><br>
>         >         Should we for example focus on matrix operations, or<br>
>         on<br>
>         >         specific<br>
>         >         preconditioners or solvers? Where would be a good<br>
>         place to<br>
>         >         start?<br>
>         ><br>
>         >         Can you suggest some specific routines/functions in<br>
>         PETSc that<br>
>         >         are<br>
>         >         potential candidates for acceleration?<br>
>         ><br>
>         > We are actually already working on this, and I plan on<br>
>         having a<br>
>         > PETSc-GPU<br>
>         > come out at the end of the year.<br>
><br>
><br>
>         What language are you using? I would have thought that OpenCL<br>
>         would be<br>
>         the best solution. Maybe even rewriting the whole of PETSc in<br>
>         OpenCL,<br>
>         targeting both multicore CPUs and a few novel architectures at<br>
>         the same<br>
>         time. AMD and NVIDIA are both going to support OpenCL for<br>
>         their GPUs and<br>
>         I believe that it will be supported on Intel's larrabee and<br>
>         the Cell<br>
>         processor.<br>
><br>
> That is probably a mistake. OpenCL is not mature and only a few<br>
> operations in<br>
> PETSc would really benefit.<br>
</div></div>I would still be interested in what language you are using for PETSc-GPU<br>
and what PETSc-GPU is?</blockquote><div><br>I would like to use OpenCL, but CUDA is it right now.<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>
>   Matt<br>
><br>
><br>
>         Ahmed<br>
><br>
><br>
>         > Therefore, I suggest working on PCs that<br>
>         > are specific to your problems. People are already doing good<br>
>         work on<br>
>         > sparse<br>
>         > matrices in general, and solvers will see no speedup at all,<br>
>         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<br>
>         confidential and<br>
>         >         privileged information. If you are not the intended<br>
>         recipient,<br>
>         >         please notify the sender immediately by return<br>
>         e-mail, delete<br>
>         >         this<br>
>         >         e-mail and destroy any copies. Any dissemination or<br>
>         use of<br>
>         >         this<br>
>         >         information by a person other than the intended<br>
>         recipient is<br>
>         >         unauthorized and may be illegal.<br>
>         ><br>
>         ><br>
>         ><br>
>         > --<br>
>         > What most experimenters take for granted before they begin<br>
>         their<br>
>         > experiments is infinitely more interesting than any results<br>
>         to which<br>
>         > their experiments lead.<br>
>         > -- Norbert Wiener<br>
><br>
><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>