Re: [ptp-dev] The State of the TAU Plugins

[Craig Rasmussen <crasmussen@xxxxxxxx>]

On Dec 14, 2006, at 12:13 PM, wspear wrote:

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.

I would think the UI page that allows users to choose specific perf monitoring capabilities would be an ideal candidate for an extension point (or as part of one).  This would allow a tool to put up radio buttons with a class responding to each choice.  I suppose this capability should be part of an overall perf extension point (or can it standalone).  I'm just blabbering here, but it seems a general perf extension point would allow extension providers to associate classes they have created with the actions you discuss in the next paragraph.

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.

My view of an extension pt is that it is primarily a schema allowing one to associate information with tags.  We have an extension pt, org.eclipse.ptp.core.resourcemanager, that allows an extension provider to contribute a class, say org.eclipse.ptp.mpich2.core.rmsystem.MPICH2ResourceManagerFactory, conforming to a given interface.  It seems to me that one thing a perf extension pt would have is a list of instrumentation choices.

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.

Greg and I discussed this and we should provide PreParallelLaunch, ParallelLaunch, PostParallelLaunch, and JobCompletion (under whatever names) events that can be listened to.

Cheers,

Craig