The timings are already stored as
std::map<std::string, std::pair<std::size_t, double> > _timings;
inside Logger.cpp so it would be very easy to return that map:
const std::map<std::string, std::pair<std::size_t, double> >&
timings { return _timings; }
--
Anders
On Fri, Aug 22, 2014 at 02:50:12PM +0200, Jan Blechta wrote:
> Why not having list_timings(comm=COMM_SELF) so that MPI.sum(comm, ...)
> is called on data? list_timings() would do the same as it does
> now, list_timings(COMM_WORLD) would serve for other obvious use case.
>
> parameters['stdout_all_processes'] = False
> list_timings(COMM_WOLRD)
> parameters['stdout_all_processes'] = True
> would ensure that only one process prints it out which is not so nice.
> But maybe it can be improved somehow.
>
> Why returning a result as XML file rather than
> dict / std::map<std::sting, std::vector> ? User would not need
> to manipule data using some XML library.
>
> Jan
>
>
> On Fri, 22 Aug 2014 13:26:43 +0200
> Mikael Mortensen <[email protected]> wrote:
>
> > I understand that multiple communicators may be problematic, but I
> > still want to know how much time one single call to assemble takes,
> > regardless the number of CPUs. And even though it sure is interesting
> > to know the timings of each individual process, the total time is
> > still what is being used for benchmarking and to measure scaling.
> >
> > Could it be an option to have a "list_timings_single_communicator",
> > that works just like it used to? I’ve looked at the code, but
> > honestly I find it a tad hard to follow what is actually going on
> > between all the loggings and the logmanagers. Right now it is easier
> > for me to write a few extra timing lines in Python than it is to
> > manipulate list_timings tables.
> >
> > +1 for exporting timing data to XML files.
> >
> > Mikael
> >
> >
> > On 21 Aug 2014, at 15:33, Garth N. Wells <[email protected]> wrote:
> >
> > >
> > >
> > > On Thu, 21 Aug, 2014 at 2:18 PM, Mike Welland
> > > <[email protected]> wrote:
> > >> Could list_timings() return a data structure so that the user can
> > >> implement their own statistics across processors (eg: Max / min &
> > >> mean)?
> > >
> > > This is worth thinking about. We've been considering something
> > > related, which is exporting timing data to XML files so a user can
> > > manipulate and plot the data.
> > >
> > > Garth
> > >
> > >
> > >> On Thu, Aug 21, 2014 at 7:26 AM, Garth N. Wells <[email protected]>
> > >> wrote:
> > >>> On Mon, 18 Aug, 2014 at 8:50 PM, Mikael Mortensen
> > >>> <[email protected]> wrote:
> > >>>> Hi
> > >>>> In the latest version of dolfin list_timings() is printing out
> > >>>> one table of results for each processor and complete timings are
> > >>>> not reported. I just wanted to know if this has been a conscious
> > >>>> choice or whether it is a bug? Until recently it printed just
> > >>>> one table even in parallel. Not quite sure when it changed
> > >>>> though…
> > >>> It's a choice, but not an optimal solution. We can't assume that
> > >>> all objects are on the same communicator, so we need something
> > >>> cleverer for reporting timing in parallel. Garth
> > >>>> Best regards
> > >>>> Mikael
> > >>>> _______________________________________________
> > >>>> fenics mailing list
> > >>>> [email protected]
> > >>>> http://fenicsproject.org/mailman/listinfo/fenics
> > >>> _______________________________________________
> > >>> fenics mailing list
> > >>> [email protected]
> > >>> http://fenicsproject.org/mailman/listinfo/fenics
> > >
> >
> > _______________________________________________
> > fenics mailing list
> > [email protected]
> > http://fenicsproject.org/mailman/listinfo/fenics
>
> _______________________________________________
> fenics mailing list
> [email protected]
> http://fenicsproject.org/mailman/listinfo/fenics
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
