Skip to content

Home

Jump to bottom
congiu edited this page Sep 9, 2022 · 57 revisions

Overview

The Performance Application Programming Interface (PAPI) provides tool designers and application engineers with a consistent interface and methodology for the use of low-level performance counter hardware found across the entire compute system (i.e. CPUs, GPUs, on/off-chip memory, interconnects, I/O system, energy/power, etc.). PAPI enables users to see, in near real time, the relations between software performance and hardware events across the entire computer system.

The ECP Exa-PAPI project builds on the latest PAPI project and extends it with:

  • Performance counter monitoring capabilities for new and advanced ECP hardware, and software technologies.
  • Fine-grained power management support.
  • Functionality for performance counter analysis at "task granularity" for task-based runtime systems.
  • "Software-defined Events" that originate from the ECP software stack and are currently treated as black boxes (i.e., communication libraries, math libraries, task-based runtime systems, etc.)

The objective is to enable monitoring of both types of performance events---hardware- and software-related events---in a uniform way, through one consistent PAPI interface. Third-party tools and application developers will have to handle only a single hook to PAPI in order to access all hardware performance counters in a system, including the new software-defined events.

Documentation

Getting Help

Contributing

The PAPI project welcomes contributions from new developers. Contributions can be offered through the standard Bitbucket pull request model. We strongly encourage you to coordinate large contributions with the PAPI development team early in the process.

For timely pull request reviews and feedback, it is important to submit one (1) pull request per feature / bug fix.

In order to create a pull request on a public read-only repo, you will need to do the following:

  1. Fork the PAPI repo (click "+" on the left and "Fork this repository").

  2. Clone it.

  3. Create a feature branch for every feature, no matter how small (from branch master git checkout -b feature_branch).

  4. Make your changes and push them to remote (git push -u origin feature_branch).

  5. Click "create pull request" from your PAPI fork (not the PAPI repo) in bitbucket.

  6. Optionally, rebase the feature branch onto PAPI master before merging (see below).

Git merge model

PAPI adopts the git merge model. This means that new features get integrated into the history through merge commits. A clean history would look something as follows:

*   185dcb38b Merge pull request #xxx from neo/rocm_feature_branch
|\
| * efdcf6512 rocm: add tests for introduced changes
| * 55ebf1416 rocm: make changes to rocm component
|/
*   b2b142317 Merge pull request #yyy from morpheus/cuda_feature_branch
|\
| * 2e7a0bbe4 cuda: add matrix multiplication test
|/
*   220b0f28e Merge pull request #zzz from trinity/libpfm4_udpate_branch
|\
| * 42df8d271 libpfm4: update to latest master
|/
*   2cac08381 Merge pull request #xyz ...

The above history is the result of rebasing feature branches onto PAPI master before merging. To rebase a feature branch onto PAPI master contributors can do the following:

  1. Add a remote for PAPI master into their local: git remote add upstream https://www.bitbucket.org/icl/papi.git

  2. From the local master branch do: git fetch upstream master && git reset --hard FETCH_HEAD

  3. Switch to the feature branch and do: git rebase master

  4. Optionally, if conflicts are detected during rebase, resolve them, add changes to the staging area and continue rebasing: git add -u && git rebase --continue

  5. Finally, push the rebased feature branch to the remote: git push -f origin feature_branch

Avoid using Bitbucket Sync mechanism at all costs. This results into loopy histories that are hard to read and backtrack.

Resources

License

Copyright (c) 2019, University of Tennessee
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
    * Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.
    * Redistributions in binary form must reproduce the above copyright
      notice, this list of conditions and the following disclaimer in the
      documentation and/or other materials provided with the distribution.
    * Neither the name of the University of Tennessee nor the
      names of its contributors may be used to endorse or promote products
      derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL UNIVERSITY OF TENNESSEE BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Clone this wiki locally