-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate Caliper #331
Integrate Caliper #331
Conversation
6ce1c05
to
8318ee1
Compare
|
8573ef9
to
7c14475
Compare
@@ -308,6 +341,7 @@ class KernelBase | |||
MPI_Barrier(MPI_COMM_WORLD); | |||
#endif | |||
timer.start(); | |||
CALI_START; |
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.
I put CALI_START
after and CALI_STOP
before the existing timers. Is this acceptable? I assume if someone turns caliper on they would be looking at those timings so they should be more accurate and in the opposite case caliper would be off so it shouldn't impact the original timers that much. Not sure how much impact this has.
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.
I think that choice makes most sense.
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.
If Caliper is off, do the macros become no-ops with a simple run time conditional evaluation?
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.
Yes. If RAJAPerf is not built with caliper, RAJA_PERFSUITE_USE_CALIPER=OFF
, the macros will be defined as here, so the only operation will be the #if defined(RAJA_PERFSUITE_USE_CALIPER)
.
|
41b7683
to
fec89f1
Compare
std::string gstr = getGroupName(kstr); \ | ||
std::string vstr = "RAJAPerf"; \ | ||
CaliMeta(); \ | ||
CALI_MARK_BEGIN(vstr.c_str()); \ |
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.
This doesn't look right to me. Is 'vstr' the "variant" name? If so, then it seems like it should be set by calling getVariantName(), which takes a VariantID enum value.
Am I misunderstanding this?
Also, it feels like we can set up some special utility methods to avoid having to re-parse strings to extract substrings repeatedly.
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.
We specficially moved away from getVariantName()
to a static string, RAJAPerf
, so different runs will not have different top-level node names. This fits the standard expected by our tools. This information should instead be collected in the metadata, as shown here.
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.
OK. I'm still confused about this. I can ask you about it later sometime.
Addressed in c0197bf. Generate a single cali file per variant, tuning combo. |
…sts in the metadata.
…ce instead of per tuning
…ze into all kernels that contain boilerplate
04d1e62
to
d012525
Compare
New commits on #352 |
Caliper Integration for RAJAPerf
This work is a variant of #254
This is dependent on #333 #335