On 10/5/07, Dan Terpstra <terpstra@xxxxxxxxxxxx> wrote:
Wyatt -
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?
I do not have any machine or event-volume specific code at this point, so it just produces a very long flat list of checkboxes. A hierarchal/tree based structure is probably the best way to handle this, so long as there is a consistent way to categorize subsets of events. A search or filter function might be a good idea too. Most of the selector tool's overhead is in checking for and disabling events incompatible with the current selections, but I haven't yet tested on a system with enough events to appreciably degrade the selector's response time.
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.
Please let me know if I can offer any assistance with this.
One feature on the to-do list for the plugins now is a component of the tool-definition xml file that allows tool-specific usage of selected PAPI events. The same GUI will be used for selecting events for every tool, but how the selected events are passed as arguments or stored as environment variables should be customizable without hard-coding a new plugin to define the behavior.
-Wyatt
- 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
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
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev