XPRESS: Collaboration on System Performance

We are happy to host the ‘XPRESS Workshop on System Performance’ this week Wednesday (February 6th) until Friday (February 8th) at LSU in Baton Rouge. We will meet in R331 Johnston Hall on LSU’s campus.


Wednesday, February 6th, 2013
9:30-10:00 Welcome (Hartmut Kaiser, CCT at LSU)
10:00-11:00 TAU – Performance Measurement Technology (Kevin Huck, UO)
11:00-12:00 RCRToolkit (Allan Porterfield, RENCI at UNC)
12:00-01:00 HPX Performance Counters (Hartmut Kaiser, CCT at LSU, Maciej Brodowicz, IU)
01:00-02:00 Lunchbreak
Afternoon Discussions, coding sessions
Thursday, February 7th, 2013
09:00-10:00 APEX – Design Proposal for XPRESS (Kevin Huck, UO)
10:00-11:00 Performance Metrics as the Software Stack Backbone (Allan Porterfield, RENCI at UNC)
11:00-12:00 Measuring and Modelling Performance (Hartmut Kaiser, Bryce Lelbach, Vinay Amatya, CCT at LSU)
12:00-01:00 Lunchbreak
01:00-01:30 Building HPX (Bryce Lelbach, CCT at LSU)
Afternoon Discussions, coding sessions
Friday, February 8th, 2013
09:00-10:00 Instrumenting HPX (Hartmut Kaiser, CCT at LSU)
09:00-12:00 Discussions, summary, planning
12:00-01:00 Lunchbreak

Meeting Summary

The meeting summary notes are available here.

Summary of presentations

TAU – Performance Measurement Technology (Kevin Huck, UO)

The TAU Performance Measurement System is more than just timers, counters and samples. In this talk, we will present an overview of the TAU ecosystem of available technology that can play a role in the XPRESS project, such as auto instrumentation and library wrapping, as well as performance measurement.

APEX – Design Proposal for XPRESS (Kevin Huck, UO)

APEX is envisioned as more than just performance measurement. Rather than blindly passing on self-reported measurements, APEX will examine the top-down and bottom-up states to examine the full reporting context, scanning for performance anomalies. APEX components will report the good/bad states of each layer to RCRBlackboard, as well as observe the states of the other layers in order to provide full performance context. Performance measurements will be handled with an event-driven model, with out-of-band processing and interaction with the Blackboard to minimize interference with the currently executing layer behavior, whether it is handling a sample, timer, counter or state transition. APEX will be explicitly designed to meet the needs of the ParalleX performance model.

RCRToolkit (Allan Porterfield, RENCI at UNC)

A small toolkit focusing on 3rd person performance analysis (your performance depends on what you and any concurrently running threads are doing). Consists of RCRdaemon, RCRlogger, RCRTool and Qthreads Sherwood scheduler. RCRdaemon: kernel level daemon that maintains a self-describing data structure (currently Google protobuf) in a shared memory region containing socket-wide performance counters (currently energy and memory concurrency). Locks on the data are avoided by only allowing one writer (multiple readers) to a region of the shared memory. RCRlogger: read the contents of the share memory region and save into a file for post-execution analysis. RCRTool: a very simple GUI for post-execution analysis. Qthread Sherwood scheduler extension: Uses performance data to throttle parallelism during regions where power and memory concurrency are both high — e.g where spending a lot of power ban suffering from performance limitations because of limited share hardware resources.

Performance Metrics as the Software Stack Backbone (Allan Porterfield, RENCI at UNC)

Currently RCR deals works on single node systems. Need to develop mechanisms to extend to multi-node systems – must make sure it scales (limited data and limited communication). Need to make available information across levels in the software stack to allow informed integrated decisions to be made about performance, energy and reliability. Data: Hardware – “standard” performance and health (energy, temperature, hardware error etc) — Software – information about decisions made (probably mostly scheduling or resource allocation). Hooks to allow access to during and after application execution. — improve OS/workflow/runtime scheduling — allow upper-level schedulers to energy and reliability information to improve resilience. Hooks to allow scheduling both on node and across nodes to use dynamic information to improve performance, energy usage and reliability. (wait times, temperatures, ecc errors should all help different aspects of the problems) .

HPX Performance Counters (Hartmut Kaiser, CCT at LSU, Maciej Brodowicz, IU)

This presentation gives a short overview about the HPX Performance Counter Framework. We describe the concepts and demonstrate the API. Performance Counters in HPX are representations of an arbitrary data source. All data sources are exposed through a uniform API which allows to create, query and discover available Performance Counters. We show some simple examples demonstrating how to use the existing Counters and how to create custom, application specific Counters. Additionally we will present the current state of the HPX PAPI Performance Counter component.

Measuring and Modelling Performance (Hartmut Kaiser, Bryce Lelbach, Vinay Amatya, CCT at LSU)

We present a simple but generally useful performance model – the Universal Scalability Law (USL). The USL can be used to estimate the best possible amount of resources to utilize for a particular problem based on a couple of collected data points. Based on concrete HPX micro benchmarks and real applications we compare the measurement results with the data predicted by the USL.

GD Star Rating

Leave a Reply

Your email address will not be published. Required fields are marked *