Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [ptp-dev] New TAU plugins

Wyatt -


From: ptp-dev-bounces@xxxxxxxxxxx [mailto:ptp-dev-bounces@xxxxxxxxxxx] On Behalf Of wspear
Sent: Thursday, October 04, 2007 5:15 PM
To: Parallel Tools Platform general developers
Subject: Re: [ptp-dev] New TAU plugins

 

Dan,

Something like that could be quite helpful, actually.  Parsing the current output isn't too difficult but I bet I am not the only one who will want to use information from these tools programmatically.  Right now I do support both native and preset events, but they are mutually exclusive because of the selector logic.  I need to rework the logic of the tool significantly. 

How do you handle machines like opteron or Core2 where the current PAPI reporting of native events can produce thousands of variations?


What would be really nice is a tool that works like papi_event_chooser but that returns all event types at once (native preset or otherwise), under headings that indicate their category.  If it could classify counters by relevant subcategories that would also be very useful.  I have been considering how to implement logic like this in the Eclipse selector tool, but if it is something that might get done on the PAPI side I would be happy to wait and take advantage of that.

I’ll need to think a bit more about this, but it should be easier on the PAPI end than on the Eclipse/TAU end.

- dan


Regards,
Wyatt

On 10/4/07, Dan Terpstra <terpstra@xxxxxxxxxxxx> wrote:

Wyatt –

We're in the process of bringing up an Eclipse/PTP/TAU sandbox on a small Core2 cluster here at UTK. I want this particularly to begin getting a feel for what you're doing in your PAPI plugin. A conversation with Sameer yesterday got me thinking about what needs to happen on the PAPI side to make the plugin side easier. He mentioned that you are parsing native events as well as preset events. Is that the case or just the goal? Do you have specific thoughts on what we can do in papi_avail or papi_native_avail to make your life easier?

For example, we could certainly produce a papi_elipse_avail or papi_xml_avail that could spit this info out in a format more easily consumed by another program…

- dan

 

 


From: ptp-dev-bounces@xxxxxxxxxxx [mailto:ptp-dev-bounces@xxxxxxxxxxx] On Behalf Of wspear
Sent: Friday, September 28, 2007 6:27 PM
To: Parallel Tools Platform general developers
Subject: [ptp-dev] New TAU plugins

 

Greetings,

I've put up a new patch for the TAU plugins (https://bugs.eclipse.org/bugs/show_bug.cgi?id=168292 ).  Most of my effort for the past couple weeks has gone into adding support for other, arbitrary performance analysis tools.  Compilation, execution and post-execution analysis tools are all supported now.  The next big features I will work on are support for setting tool-specific environment variables for compilation and execution and better management of arbitrary (user defined) performance analysis output.  I will also be enhancing the performance analysis launch configuration tab to show tool-option panes defined in the xml file, as TAU's compiler options settings are now.

There is a lot to be done with the core yet, but I would definitely like to look at the PAPI functionality soon as well.  The PAPI plugin is likely to be a premiere use-case for the upcoming tool environment variable management system.

If anyone has any questions or comments on the development or functionality of the plugins, please don't hesitate to let me know. 

Regards,
Wyatt


_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev

 


Back to the top