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@xxxxxxxxx>
wrote:
On Thu, May 8, 2008 at 10:09 PM, Dave May <dave.mayhem23@xxxxxxxxx>
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