Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ptp-dev] The State of the TAU Plugins

Greetings,

Most of the 'guts' of the plugins are fairly specific to TAU.  Alan did most of the work on the perfdmf plugin, but its UI and source-callback components seem fairly general, while the rest of its internal implementation is fairly specific to TAU's perfdmf database.  The selective instrumentation plugins allow the user to specify source code in the editor or elements of the source tree, but what gets done with those selections is entirely TAU specific.   Similarly, as I mentioned earlier, the TAU launcher plugin has a general 'before, during and after parallel execution' work flow, but the actual work done in those phases is going to be almost entirely tool specific as well.  I'm not sure if there are specific implementations that would be useful to all, or even most, performance analysis tool developers.  As things stand now, a generic performance analysis plugin would consist of interfaces and empty example implementations.  It would basically duplicate the standard PTP launcher, but in a distinct launch configuration window, until someone added some meat.

The TAU launcher plugin uses the org.eclipse.debug.core.launchDelegates, org.eclipse.debug.ui.launchConfigurationTabGroups and org.eclipse.(tool).ui.(tool)Perspective extension points at present.  The generic plugin could encapsulate these and call for the user's implementation of LaunchConfigurationDelegate and LaunchConfigurationTab, or some performance specific subclasses.  I haven't looked at creation of extension points before, so my focus here will likely remain on decoupling and abstraction of the code for the time being.

The launchDelegates extension point covers my requirements for the launcher pretty well so far.  I'm just creating a new delegate that extends the PTP's.  The main trouble I'm having with the launcher is getting feedback on when the execution is totally complete and all of the output has been produced, or when it fails.  Right now I'm stuck busy-waiting and relying on the user to cancel if anything goes wrong in recompilation or execution.  I don't think that's anything an extension point can help though.

Regards,
Wyatt


On 12/14/06, Greg Watson <g.watson@xxxxxxxxxxxx> wrote:
Wyatt,

This sounds great. I have a couple of questions. How much of this is
TAU specific, and how much could be used as a generic framework for
performance tools? Would it be possible to split this into a core
plugin that exposes some extension points, and a TAU plugin that
implements the TAU-specific part? Also, can you provide any
suggestions on extension points that would make it easier for you to
use the launcher?

Thanks,

Greg


On Dec 12, 2006, at 4:18 PM, wspear wrote:

> Greetings,
> Here is a quick overview of the TAU plugins as they stand now and
> their impending improvement.
>
> As demonstrated at Supercomputing, the plugins have been almost
> totally overhauled from the previously committed versions.
> Instrumentation options have been moved from a workspace-wide
> options panel to a run-configuration specific performance analysis
> tab.  Profile data is now collected in and displayable from a
> database navigable within Eclipse.  TAU's selective instrumentation
> capabilities were given an interface within the Eclipse workspace.
>
> Since Supercomputing there have been several bugfixes and
> architectural changes.  The TAU plugin's Launch Configuration
> Delegate now essentially wraps the PTP's.
>
> Presently the scheme for performance analysis launching is a basic
> three part process.  First there is a pre-execution phase (here TAU
> (harmlessly) re-compiles the project with its compiler wrapper
> scripts).  Then comes the launching phase, which for the TAU plugin
> consists of calling the PTP's launcher normally, but substituting
> the TAU-instrumented executable.  Finally, after the process
> finishes running, the post-execution phase kicks in.  Here TAU
> collects and stores performance data output and cleans up any
> unwanted build configurations.  The generic scheme of 'things done
> before execution', execution and 'things done after execution' is
> likely to apply to most performance analysis tools, but it will be
> difficult to tighten up the launch delegate's interface much beyond
> that, given the diversity of performance analysis tools' usage
> requirements.  Similarly, the contents of the performance analysis
> launch configuration tab and any workspace options are entirely
> dependent on the options available to the tool in question.
> Removing the TAU specific elements of the plugins would leave a
> serviceable shell for integration of other performance analysis
> tools plugins, but the plugin developers will have to do a lot of
> work specific to the functionality of their system.  Other issues,
> such as support for multiple performance analysis plugins at once,
> haven't received much attention yet.  I suspect the single most
> useful thing for the performance analysis plugin framework now
> would be some how-to documentation with the TAU plugin as an example.
>
> New features added since Supercomputing include a PAPI event
> counter selection tool.  When PAPI is available this allows you to
> select PAPI counters from a checklist, which marks mutually
> exclusive counters as you proceed.  The selected counters are
> automatically defined in the project's environment.  The mechanism
> for selecting TAU makefiles has also been improved.  The list of
> check boxes for specifying TAU features is now used to narrow down
> a list of available makefiles, with unavailable makefile options
> dynamically disabled.
>
> Upcoming changes (hopefully within the next few days) include the
> addition of help and usage information to the interface and
> improved control of performance data output and storage.
>
> Longer range goals include improvements to the build and launch
> progress monitoring system, creation of a version of the TAU
> launcher plugin (the selective instrumentation, PAPI and profile
> view plugins are universal) for non-parallel programs (making two
> versions of the TAU launcher plugin should help with developing the
> general performance plugin framework), better support for the
> standard make system, addition of more TAU compilation and runtime
> options, automatic selective instrumentation calculated by analysis
> of previous execution profiles and support for multi-run experiment
> batch launching.  Please let me know if there are any features or
> fixes you would like to see.
>
> I will try to submit a new version of the TAU plugins to bugzilla
> before Christmas.
>
> Happy Holidays,
> Wyatt Spear
> _______________________________________________
> 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



Back to the top