On 9/28/07, Beth Tibbitts <tibbitts@xxxxxxxxxx> wrote:
Yes we talked about that; sorry I haven't implemented anything yet.
We could store it within the eclipse preferences, but if so we would need
an import/export feature (not difficult) to put it in a file format that
could be
(1) read by a variety of tools and (2) checked into a repository, or
otherwise shared between users.
When you say "internally stored" I presume you mean eclipse preferences,
preferenceStore, etc.
The selective instrumentation system for the performance plugins already contains a set of functions for reading in a selective instrumentation file to make whatever changes and writing it back out again. These could be modified to act as import/export functions without much trouble. They are specific to TAU instrumentation commands now, but it wouldn't be difficult to make something more general.
I don't understand your comment about getting the components to talk to one
another. Any eclipse component should be able to access the Preferences;
put a reference to them in the PlugIn (Activator) class for a plug-in to
make access the most convenient, and share the constant keys used to access
them
in some central place like that as well (Plugin/Activator, or an IDs class
for instance)
The preferences system seemed like the most likely method to me too. My concern with it was that selective instrumentation data has to be associated with a specific project rather than with the global workspace, which is what the preferences system seems to support most naturally. I can think of a couple ways to do this but I'm not sure if there's a 'best practice' for it.
I hope to get time to review the rest of Wyatt's contribution in the
referenced bugzilla patch below, and check it in, hopefully soon.
I was able to load/review the part that doesn't depend on PTP Core so far,
working with Wyatt.
And yes, I can help with the extension points when we get there too.
Comments from the community are very welcome on this!
...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
wspear
<wspear@cs.uorego
n.edu> To
Sent by: "Parallel Tools Platform general
ptp-dev-bounces@e developers" <ptp-dev@xxxxxxxxxxx>
clipse.org cc
Subject
09/27/2007 09:12 Re: [ptp-dev] Performance Tools
PM Framework
Please respond to
Parallel Tools
Platform general
developers
<ptp-dev@eclipse
.
org>
Beth, I was wondering about the status of your selective instrumentation
work. As I recall you were looking into storing within eclipse itself user
specified information on what routines should and shouldn't be selected for
instrumentation, as opposed to on the file system, and on marking elements
selected or excluded for instrumentation within the editor.
The difficulty I've had with my initial approach to this has been getting
the different components to talk to each other. The selection takes place
in the editor/workspace but I haven't found a good 'Eclipse-y' way to make
information associated with the editor easily accessible by the launch or
build systems, which are what ultimately put the selective instrumentation
data to use. Internally stored selective instrumentation data will be
useful, in particular, for generating selective instrumentation files for
multiple tools from a single source.
This is becoming more relevant as the latest batch of updates to the
performance plugins (https://bugs.eclipse.org/bugs/show_bug.cgi?id=168292
)
offers support for multiple user-defined performance tools. This includes
tools like psrun that take the program to be analyzed as an argument and
tools like TAU that recompile with instrumentation. The next release
should be generalized enough to support all the performance tools I've been
able to get my hands on to test. There is also some rudimentary support
for tool workflow, which I hope to expand on soon.
I still need to work on developing extension points for the plugins. Right
now they read an arbitrary XML file for tool definitions. These high-level
tool definitions work for some tools while others (TAU included) have more
complicated interfaces that may require tool-specific extensions.
Regards,
Wyatt
On 8/18/07, Beth Tibbitts <tibbitts@xxxxxxxxxx> wrote:
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
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.
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
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
