bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Would timevar be accepted in gnulib?


From: Akim Demaille
Subject: Re: Would timevar be accepted in gnulib?
Date: Sun, 23 Sep 2018 15:29:36 +0200

Hi!

> Le 23 sept. 2018 à 15:08, Bruno Haible <address@hidden> a écrit :
> 
> Hi Akim,
> 
>>> What do you think? Do you think the list-of-lists use-case makes sense?
>>> Do you think configuring the list at run time is something people may want
>>> to do?
>> 
>> You have a strong point here.  But I don’t know if there would
>> be actual users for such dynamic timers.
> 
> OK, no dynamically allocated timevars then.
> 
> But what about the list-of-lists use-case? I think it's pretty natural that,
> when a computation consists of several phases, each (or at least some) of
> the phases consists of several sub-phases.

I agree with this, but that’s already quite advanced usage.
timevar aims at a really simple model (which yet seemed to
suffice for GCC).  If I were to do something like that, I
guess I would use something like

DEFTIMEVAR (TV_FOO,     "Foo phase")
DEFTIMEVAR (TV_FOO_BAR, "Foo: Bar phase")
DEFTIMEVAR (TV_FOO_BAZ, "Foo: Baz phase")

It seems they did not change much the model in GCC, but made it
C++.

https://github.com/gcc-mirror/gcc/blob/master/gcc/timevar.h
https://github.com/gcc-mirror/gcc/blob/master/gcc/timevar.c
https://github.com/gcc-mirror/gcc/blob/master/gcc/timevar.def

Yet they added some support for dynamically allocated timers.

https://github.com/gcc-mirror/gcc/blob/b3b24aa82c0ffc77f479e90e75197b517e184547/gcc/timevar.c#L125

>> I guess I should have said
>> ’set’ instead of ‘list’, the order does not matter, except for
>> the order used to display the result.
> 
> Since the order matters for printing, it’s a 'list', not a 'set'.

Sure.  What I meant is that this is the only place it’s used.
There’s no static relationship between timers, only the push/pop
matter, and they give no special structure to the nested timers.
Which is a feature: it does no follow the hierarchical structure
that profiler try to show for function calls.  That’s not the
point here.  You might want how much logging (roughly) costs you
overall, not how much logging costs for each other timer.


>>> Approaches (b), (c), (d) have the advantage that the abstraction is easier
>>> to understand, because it follows common C idioms (define structs and 
>>> reference
>>> them through pointers instead of IDs).
>> 
>> I disagree here.  You seem to claim that an abstraction is easier
>> to understand when you understand the implementation, which kind
>> of defeats the point of the abstraction.
> 
> I like abstractions too. But I also see that many people have problems
> grokking abstractions when they don't see the implementation or when the
> abstractions are not well explained.

Sure!  The documentation should make it clear how to use timevar,
and its defining macro.

In Bison it reads:

/* This file contains timing variable definitions, used by timevar.h
   and timevar.c.

   Syntax:

     DEFTIMEVAR (id, name)

   where ID is the enumeral value used to identify the timing
   variable, and NAME is a character string describing its purpose.  */

/* The total execution time.  */
DEFTIMEVAR (TV_TOTAL                 , "total time")

/* Time spent in the reader.  */
DEFTIMEVAR (TV_READER                , "reader")
DEFTIMEVAR (TV_SCANNING              , "scanner")
DEFTIMEVAR (TV_PARSING               , "parser")

/* Time spent handling the grammar.  */
DEFTIMEVAR (TV_REDUCE                , "reducing the grammar")
DEFTIMEVAR (TV_SETS                  , "computing the sets")
DEFTIMEVAR (TV_LR0                   , "LR(0)")
DEFTIMEVAR (TV_LALR                  , "LALR(1)")
DEFTIMEVAR (TV_IELR_PHASE1           , "IELR(1) Phase 1")
DEFTIMEVAR (TV_IELR_PHASE2           , "IELR(1) Phase 2")
DEFTIMEVAR (TV_IELR_PHASE3           , "IELR(1) Phase 3")
DEFTIMEVAR (TV_IELR_PHASE4           , "IELR(1) Phase 4")
DEFTIMEVAR (TV_CONFLICTS             , "conflicts")

/* Time spent outputing results.  */
DEFTIMEVAR (TV_REPORT                , "outputing report")
DEFTIMEVAR (TV_GRAPH                 , "outputing graph")
DEFTIMEVAR (TV_XML                   , "outputing xml")
DEFTIMEVAR (TV_ACTIONS               , "parser action tables")
DEFTIMEVAR (TV_PARSER                , "outputing parser")
DEFTIMEVAR (TV_M4                    , "running m4")

/* Time spent by freeing the memory :).  */
DEFTIMEVAR (TV_FREE                  , "freeing")


>>> (d) has the further big advantage that the list can be configured at run 
>>> time.
>>> For example, if a compiler has dynamically loadable passes (like GNU ld),
>> 
>> Really?  ld is dlopening some of its passes?
> 
> Yes. I meant the link-time optimization. See '-fuse-linker-plugin' in
> https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Optimize-Options.html

Thanks!  I had not realized LTO used such an approach.  But now,
thinking about it, it’s quite obvious ld won’t include a compiler…


reply via email to

[Prev in Thread] Current Thread [Next in Thread]