[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[ptp-dev] Re: ptp-dev Digest, Vol 29, Issue 20
|
I just had a conversation with Beth about this. To keep a persistent
record, I've interspersed my comments below.
-- Rob
ptp-dev-request@xxxxxxxxxxx wrote:
Message: 1
Date: Sat, 18 Aug 2007 13:54:27 -0400
From: Beth Tibbitts <tibbitts@xxxxxxxxxx>
Subject: [ptp-dev] Performance Tools Framework
To: ptp-dev@xxxxxxxxxxx
Message-ID:
<OF4D6F8DB8.14BE3386-ON8525733B.005E39B3-8525733B.00625E8C@xxxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII
We are working on generalizing some performance tools integration work with
PTP and Eclipse.
So that we can reuse the "Eclipse plumbing" that plug-in work for TAU (U.
Oregon), TuningFork (IBM) and PAPI etc. (U. Tenn.) are developing,
We are working on providing the generic work within a framework such that
less work has to be done for each new tool integration.
For an outline of the 5 basic points of integration that seem to be most
readily generalized,
see the wiki at: http://wiki.eclipse.org/PTP/designs/perf_tools_framework
But, basically these five points are:
1. Instrumentation
2. Build, which may or may not be transparent to user
3. Launch with instrumentation
4. Management of profile/trace data
5. Visualization / Analysis of profile/trace data
I've got a slightly more refined conceptual model, which is close to these 5 points,
so I've tried to use a consistent numbering scheme
.
0. Shared tool configuration and script creation/management usable by all
other parts.
1. Multiple levels of source transformation including source-source compilation
tools, macro pre-processors (m4, cpp, etc.), and source instrumentors. (Which
source? Pre- or post- preprocessing?)
2. Build emitting load module, either executable or .so. Record provenance info.
3. Launch -- vanilla, or with data collection. Batch or interactive, i.e. with
debugging, on-line monitoring, or monitoring and steering.
3a. On-line debugging, monitoring, steering, or vis., if launched in appropriate mode.
4a. Data aggregation and collection, i.e. moving data from where generated to where
analysis will be performed.
4b. Management of data once collected.
5. Post mortem analysis and vis.
To start with I am prototyping some eclipse tools to assist users in adding
performance
instrumentation lines to source code. So far about 90% of the code is in a
generic plug-in to which
the user/client writes an extension plug-in that uses that and requires
very little code to implement.
Next I will work on instrumentation that doesn't modify the user's source
code at all,
a "transparent" instrumentation that e.g. instruments a copy of the source
code then builds.
In order to keep a persistent, consistent view of what happened, it's important
that the instrumentation history be preserved, e.g, keep an explicitly instrumented
copy of the source somewhere, perhaps as a log or a diff.
This is an important part of the provenance meta-data that's necessary in order
to interpret the measurements correctly.
Others may be working on other areas of the framework. Stay tuned for more
details.
As we firm up the details we will expand the information on the wiki page
listed above.
I just wanted to make sure that information made it to the ptp-dev list to
inform others.
...Beth
Beth Tibbitts (859) 243-4981 (TL 545-4981)
High Productivity Tools / Parallel Tools http://eclipse.org/ptp
IBM T.J.Watson Research Center
Mailing Address: IBM Corp., 455 Park Place, Lexington, KY 40511
------------------------------
Message: 2
Date: Sat, 18 Aug 2007 21:08:09 -0700 (PDT)
From: Sameer Shende <sameer@xxxxxxxxxxxxxx>
Subject: Re: [ptp-dev] Performance Tools Framework
To: Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
Message-ID:
<Pine.OSX.4.53.0708182053390.21566@xxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi Beth,
1. Instrumentation
2. Build, which may or may not be transparent to user
...
Next I will work on instrumentation that doesn't modify the user's source
code at all,
a "transparent" instrumentation that e.g. instruments a copy of the source
code then builds.
We have implemented such an approach with the TAU instrumentor. We
^^^^^^^^^^^^^^^^
See comments a above r.e. provenance. Where are the copies of the source
kept and what's done to keep a persistent record?
insert instrumentation calls in a copy of the source file and compiles it
to produce the .o file. We have shell scripts (tau_f90.sh,
tau_cc.sh, tau_cxx.sh) that act like compilers, and modify only a copy
of the original source code. Currently the tau_instrumentor supports:
* routine level instrumentation in C, C++ and Fortran
* outer-loop level instrumentation in these languages
* selective instrumentation based on exclude/include lists from routines/files.
* I/O instrumentation for Fortran
* memory allocation/deallocation instrumentation in Fortran
We are now adding support for user-specified application level
phases. We hope to provide support for both static as well as dynamic
phases that track the full flat profile of events that are invoked within
a phase boundary (start/stop). Static phases aggregate data from all
invocations while dynamic phases show data for each instance of a phase.
It may be useful to re-use this instrumentation that TAU provides.
What do you feel?
Wyatt is working on a scheme to help integrate TAU and other tools
within PTP. Our goal is to build a graphical instrumentation tool within
Eclipse/PTP that describes the above instrumentation requests to any
performance tool. These requests (in an instrumentation specification
file) will not contain any TAU specific calls, but (when fully
implemented) be higher-level. Then, any tool could choose to implement
part or all of these instrumentation requests. Currently, our plugin does
use some code that is TAU specific (to describe phase based
instrumenation), but soon it will be independent of TAU in the manner it
describes the instrumentation requests (e.g., instrument outer loops in
routine foo, instrument using dynamic timers lines <start> to <stop> and
using a user specified name etc.)
Wyatt can provide you more details of the plugin.
Thanks,
- Sameer
------------------------------
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
End of ptp-dev Digest, Vol 29, Issue 20
***************************************
--
Robert J. Fowler
Director of HPC Research
Renaissance Computing Institute
The University of North Carolina at Chapel Hill
100 Europa Dr, Suite 540
Chapel Hill, NC 27517
V: 919.445.9670
F: 919 445.9669
rjf@xxxxxxxxx
