Pr from fork/137 #254
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -159,3 +159,72 @@ storing the result in matrix A (N_i X N_j). Problem size could be chosen to be | |
| the maximum number of entries in matrix B or C. We choose the size of matrix | ||
| A (N_i * N_j), which is more closely aligned with the number of independent | ||
| operations (i.e., the amount of parallel work) in the kernels. | ||
|
|
||
|
|
||
| =========================== | ||
| Caliper output files | ||
| =========================== | ||
|
|
||
| If you've built RAJAPerf with Caliper support turned on, then in addition to the | ||
| outputs mentioned above, we also save a .cali file for each variant run, such as: | ||
| Base_OpenMP.cali, Lambda_OpenMP.cali, RAJA_OpenMP.cali, etc. | ||
|
|
||
| There are several techniques to display the Caliper trees (Timing Hierarchy) | ||
|
|
||
| | 1: Caliper's cali-query tool. | ||
| | The first technique is with Caliper's own tool cali-query, we run it with | ||
| | **-T** to display tree, or you can specify **--tree**. | ||
| | | ||
| | cali-query -T $HOME/data/default_problem_size/gcc/RAJA_Seq.cali | ||
|
|
||
| 2: Caliper's Python module *caliperreader*:: | ||
|
|
||
| import os | ||
|
There was a problem hiding this comment. Does this live in a file someplace? If so, we should include it here using comment delimiters in that file so that the docs here don't get out of sync with the script file. There was a problem hiding this comment. No, this is a sample script embedded in the docs. This and the one below I thought small enough to be included inline. I will revisit the small Hatchet script wrt divergence issues between the LC Hatchet, and PYPI Hatchet when Stephanie includes her updates. But, I see your point especially with my comment concerning version divergence. Maybe I can move it into the CI script as a free function, that can then be refer'ed to in the doc. What do you consider best practice wrt display snippets or gists in the documentation, where gists are maintained separately but get built into rst There was a problem hiding this comment. That would be good so it can be updated if needed and simplify doc maintenance. |
||
| import caliperreader as cr | ||
| DATA_DIR = os.getenv('HOME')+"/data/default_problem_size/gcc" | ||
| os.chdir(DATA_DIR) | ||
| r = cr.CaliperReader() | ||
| r.read("RAJA_Seq.cali") | ||
| metric = 'avg#inclusive#sum#time.duration' | ||
| for rec in r.records: | ||
| path = rec['path'] if 'path' in rec else 'UNKNOWN' | ||
| time = rec[metric] if metric in rec else '0' | ||
| if not 'UNKNOWN' in path: | ||
| if (isinstance(path, list)): | ||
| path = "/".join(path) | ||
| print("{0}: {1}".format(path, time)) | ||
|
|
||
| You can add a couple of lines to view the metadata keys captured by Caliper/Adiak:: | ||
|
|
||
| for g in r.globals: | ||
| print(g) | ||
|
|
||
| You can also add a line to display metadata value in the dictionary **r.globals** | ||
|
|
||
| For example print out the OpenMP Max Threads value recorded at runtime:: | ||
|
|
||
| print('OMP Max Threads: ' + r.globals['omp_max_threads'])` | ||
|
|
||
| or the variant represented in this file:: | ||
|
|
||
| print('Variant: ' + r.globals['variant']) | ||
|
|
||
|
|
||
| .. note:: The script above was written using caliper-reader 0.3.0, | ||
| but is fairly generic. Other version usage notes may be | ||
| found at the link below | ||
|
|
||
| `caliper-reader <https://pypi.org/project/caliper-reader/>`_ | ||
|
|
||
|
|
||
| 3: Using the *Hatchet* Python module:: | ||
|
|
||
| import hatchet as ht | ||
|
There was a problem hiding this comment. Similar comment as above about linking to section in the script file. |
||
| DATA_DIR = os.getenv('HOME')+"/data/default_problem_size/gcc" | ||
| os.chdir(DATA_DIR) | ||
| gf1 = ht.GraphFrame.from_caliperreader("RAJA_Seq.cali") | ||
| print(gf1.tree()) | ||
|
|
||
| `Find out more on hatchet <https://github.com/LLNL/hatchet>`_ | ||
|
|
||
|
|
||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason to have a different USE_CALIPER for each project? Caliper regions+data are composable across projects, so I wonder if there is a use case where we would want to enable caliper in one project but not another - if not, keeping it the same across projects may be nice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One rationale for the different flag was the fact that Caliper support is not in BLT, where then it could be made general, including the way the flag propagates across subprojects.