On Fri, Jan 20, 2012 at 4:59 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > On Jan 20, 2012, at 4:51 PM, Matthew Knepley wrote: > > > On Fri, Jan 20, 2012 at 4:45 PM, Paul Mullowney <paulm at txcorp.com> > wrote: > > The new code using CUSPARSE gives you triangular solves that are > supported by Nvidia. They are as fast as what was in their previously. > Advantage is that it's now fully supported by the vendor library. > > > > The matrix multiplication is more succinct than what was in petsc-dev. > Plus it has options for choosing storage format on the device for optimal > performance. > > You now have csr/coo/ell/dia formats ... Plus the SpMV scales across > multiple GPUs now. > > > > I am happy to remove printf's if that helps. > > > > Although, I care in the abstract about how code looks, I don't have > enough time to complain about it. I care in this case, > > because it does not appear to be supportable by us. If this is not true, > and someone understands all this, please say so. > > Then I will go back to not caring. > > It may easily be that some refactoring is in order. For example the > PETSc style would not have one function that handles conversion to several > different matrix formats on the GPU. Rather each conversion would have its > own (simple) function which is simplier to understand and maintain and > extend. Paul is new to PETSc development and doesn't understand all our > quirks. > > But Matt does bring up an extremely important point; PETSc code must be > clean enough and simple enough to allow any member of the team to maintain > it. If the code requires the author only to make changes to it then the > code cannot be allowed. This is why all the mesh code is being rewritten again. Matt > > Barry > > > > > Matt > > > > > > -Paul > > > > > > > >> On Fri, Jan 20, 2012 at 4:37 PM, Barry Smith <bsmith at mcs.anl.gov> > wrote: > >> > >> On Jan 20, 2012, at 4:31 PM, Matthew Knepley wrote: > >> > >> > http://petsc.cs.iit.edu/petsc/petsc-dev/rev/2a4f352daf49 > >> > > >> > What is going on here, and why can't it be done more succintly? > >> > >> Hell its GPUs, what do you expect? > >> > >> What particularly part do you feel is overly complex and could be > more succintly? > >> > >> This checkin of fixes is larger than the entire prior implementation. > Why, what is better? > >> > >> There are a ton of new functions with obscure names (unless Some has a > meaning which > >> escapes me). > >> > >> There seem to be a huge number of cases treated in enormous functions > rather than > >> factoring them out. > >> > >> Matt > >> > >> > >> Barry > >> > >> > >> > > >> > Matt > >> > > >> > -- > >> > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which their > experiments lead. > >> > -- Norbert Wiener > >> > >> > >> > >> > >> -- > >> What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which their > experiments lead. > >> -- Norbert Wiener > > > > > > > > > > -- > > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which their > experiments lead. > > -- Norbert Wiener > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120120/66043ef8/attachment.html>
