454082 - add vprof-style timing probes

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Virtual Machine, defect)

Description

[Edwin Smith]

Attachment: add tprof macros (x86 only)

VProf is so nice, lets extend it to support simple timers.

these two probes are designed to time different phases in a group; when one starts, it stops the previous one, with only one sample taken so there is no "lost" time.

_ntprof(e)    start timer e, stop previous ntprof timer.
_tprof_end()  end

It would also be nice to support independent and nestable groups so, for example, timing a short  span down in a library doesn't end the timer for some independent group of timers.

It would also be nice to have file/line based names in addition to explicit names.

Comment 1

[Moh Haghighat]

Attachment: vprof-based timers

Here are a few examples of using the tprof utility:

A nestable timer:
    _TPROF_DECL (timer, "timer name");
    _TPROF_START (timer);
    ...
    _TPROF_STOP (timer);

A continuous timer:
    _TPROF_CONT (ctimer, "timer name);
    
Continuous timers need to be declared and imported using _TPROF_GDECL and imported to other files using _TPROF_IGDECL.

Defining and importing global timers:
    _TPROF_GDECL  (timer, "timer name");  // declare a global timer
    _TPROF_IGDECL (timer);                // import a global timer

Only tprof.h needs to be added to Tamarin. The other two files, timer.cpp and timer2.cpp, are just drivers that show how to use tprof.

Continuous timers may subsume Ed's patch, but they can co-exist as well. Let me know if there were any problems or you have any comments or suggestions. I'll be out of office the entire of next week.

Comment 2

[Moh Haghighat]

Attachment: vprof-based timers

fixed a minor problem.

Comment 3

[Rick Reitmaier]

Move bug to Tamarin central and assign

Comment 4

[Rick Reitmaier]

Attachment: rev 1 - merged tprof.h changes into vprof for convenience

Further patch to support exclusive timings will be added ontop of this one.  This patch performs inclusive timings (i.e. probes may include time spent in other probes).

Comment 5

[Steven Johnson]

(patch doesn't apply cleanly against current redux tip)

Comment 6

[Rick Reitmaier]

Attachment: ver 3 - contains more winmo fixes and rebase

Comment 7

[Rick Reitmaier]

ver 3 contains
(1) support nested timing probes
(2) conversion of existing timed code to use new probes.
(3) support to send vprof output to a file.
(4) winmo/32 likes %I64d
(5) _rdtsc() to use full available resolution of timer (ticks).  Output of timer tick resolution printed as part of output.

I believe that the deopt profiling work requires the old timer macros.  Recommend adding them back-in post-patch as needed.

Comment 8

[Edwin Smith]

Comment on attachment 378446 [details] [diff] [review]
ver 3 - contains more winmo fixes and rebase

delegating review

Comment 9

[Tom Harwood]

Comment on attachment 378446 [details] [diff] [review]
ver 3 - contains more winmo fixes and rebase

The dump-to-file name is pretty idiosyncratic, can it be passed to the dump routine?

Comment 10

[Edwin Smith]

lets make sure this stuff aligns with the over-time logging; is one set of probes possible?

Comment 11

[Rick Reitmaier]

tom: we could pass the file, but it's more of a utility issue.  vprof is not enabled without a recompile and we'd like to send output to stdout by default.  Only on systems where its difficult to get stdout (say winmo) will file output be typically used.

ed: i'm guessing no.  over-time logging, I'm assuming is hand-off based, where one regions' time ends another begins.  With these probes, you time a region of code much like a stopwatch; on/off.

Comment 12

[Edwin Smith]

it turned out we needed to track nesting after all, so there might be more overlap than we thought.  I think the only difference between traditional vprof nested timers, and the over-time logging, is the window of time youre interested in.  (traditional = 1 interval for the whole program.  over time = N small intervals).

Comment 13

[Rick Reitmaier]

tom/ed: not sure what is needed to proceed?  Ed did you want Tom to check for overlap?

Comment 14

[Dan Smith]

Rick, What's the resolution of this bug? Is there a follow-on patch to deal with nesting?

Comment 15

[Rick Reitmaier]

Nesting is already part of the patch.  If there's no further objections, I'll land it.

Comment 16

[Dan Smith]

Moving to "Future" target per conversation with Rick.  If this patch is required, it should be rebased and landed.

Comment 17

[Sylvestre Ledru [:Sylvestre]]

Tamarin isn't maintained anymore. WONTFIX remaining bugs.