Reporting cpu times to profile KSPSolve (and others)

[Barry Smith]

    Dave,

     At the moment we'll leave this as something the user can easily  
do by creating their own custom KSP/SNES monitors.

    Barry

On May 9, 2008, at 1:09 AM, Dave May wrote:

> Hey Matt,
>     All I want to be able to do is generate plots of |r|/|r0| vs cpu  
> time. I presumed that such information is commonly required when  
> profiling the performance of solvers, so I thought it might be  
> something you'd consider adding support for.
>
> Cheers,
>     Dave
>
>
> On Fri, May 9, 2008 at 1:19 PM, Matthew Knepley <knepley at gmail.com>  
> wrote:
> On Thu, May 8, 2008 at 10:09 PM, Dave May <dave.mayhem23 at gmail.com>  
> wrote:
> > Hey petsc folk,
> >     What is the best way to obtain timing information to profile the
> > performance
> > of KSPSolve (or SNESSolve)? Currently I have written some specific  
> KSP
> > monitors,
> > but it I think it would be useful to have access to this  
> information all the
> > time without
> >  having to go through the monitor. It seems like each object  
> should know how
> > to time
> > some of its operations.
> >
> > It would be very useful to have functions such as
> >   KSPGetCPUTime(KSP ksp,PetscLogDouble *time)
> >  to report the total solution time required by the KSPSolve() and
> >   KSPGetCPUTimeHistory(KSP ksp,PetscLogDouble *time[],PetscInt *na)
> > which is like KSPGetResidualHistory() but returns the accumulated  
> cpu time
> > for each
> >  iterate
> >
> > It would also be useful to have a default KSP monitor which could  
> report the
> > time per iterate
> > or accumulate time. For example something like
> >   40 KSP Residual norm 1.519638506430e-01 Time 1.000000000000e-03
> >    41 KSP Residual norm 1.510346481853e-01 Time 1.510346481853e-02
> >
> > Is there a better approach to what I've been doing and are there  
> plans to
> > add any
> > additional features to help profile individual operations on each  
> object?
>
> Maybe you could motivate it by giving a use case? So far, I have  
> never needed
> anything but the KSPSolve() event and stages to separately aggregate  
> different
> types of solves.
>
>   Matt
>
> > Cheers,
> >     Dave
> --
> 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
>
>