[petsc-dev] This has officially become too ugly to read

Matthew Knepley knepley at gmail.com
Fri Jan 20 17:15:03 CST 2012


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>


More information about the petsc-dev mailing list