Energy profiling tools: Core infrastructure with timing tool and export capabilities#299
Open
ethan-puyaubreau wants to merge 9 commits intokokkos:developfrom
Open
Conversation
This was referenced Aug 15, 2025
JBludau
reviewed
Aug 15, 2025
JBludau
reviewed
Aug 15, 2025
JBludau
reviewed
Aug 15, 2025
Contributor
Author
|
@dalg24 @masterleinad Hello! I would need some review on this PR, being the baseline blocks needed the daemon system and energy measurement tools (that would also need review #300) |
JBludau
reviewed
Aug 25, 2025
JBludau
reviewed
Aug 25, 2025
JBludau
reviewed
Aug 25, 2025
JBludau
reviewed
Aug 25, 2025
JBludau
reviewed
Aug 25, 2025
Contributor
JBludau
left a comment
JBludau
left a comment
There was a problem hiding this comment.
I think we are getting there
dalg24
reviewed
Aug 26, 2025
Comment on lines
+92
to
+94
| // Stack-based timing for robust region/kernel tracking | ||
| void start_region(const std::string& name, RegionType type, uint64_t id = 0); | ||
| void end_region(); |
Member
There was a problem hiding this comment.
Fine but noting that if you can't correlate start and end of a region via some identifier then it won't be threadsafe.
dalg24
reviewed
Aug 26, 2025
ethan-puyaubreau
force-pushed
the
feature/energy-profiler-infrastructure
branch
from
a9c54ce to
5d9082f
Compare
dalg24
reviewed
Aug 28, 2025
| # - Tool interface definitions | ||
| # - Basic kernel timer tool | ||
|
|
||
| add_subdirectory(kokkos-tools) No newline at end of file |
Member
There was a problem hiding this comment.
This red circle means "no newline at end of file".
Please fix it by adding a newline character.
Same comment everywhere.
Comment on lines
+20
to
+23
| namespace KokkosTools { | ||
| namespace EnergyProfiler { | ||
|
|
||
| std::string generate_prefix() { |
Member
There was a problem hiding this comment.
Suggested change
| namespace KokkosTools { | |
| namespace EnergyProfiler { | |
| std::string generate_prefix() { | |
| std::string KokkosTools::EnergyProfiler::generate_prefix() { |
Comment on lines
+21
to
+22
| namespace KokkosTools { | ||
| namespace EnergyProfiler { |
Member
There was a problem hiding this comment.
Suggested change
| namespace KokkosTools { | |
| namespace EnergyProfiler { | |
| namespace KokkosTools::EnergyProfiler { |
ethan-puyaubreau
force-pushed
the
feature/energy-profiler-infrastructure
branch
2 times, most recently
from
6fb522b to
f2f0606
Compare
JBludau
reviewed
Aug 29, 2025
ethan-puyaubreau
force-pushed
the
feature/energy-profiler-infrastructure
branch
from
5fbccdf to
2629fad
Compare
JBludau
reviewed
Aug 29, 2025
ethan-puyaubreau
changed the title
JBludau
reviewed
Aug 29, 2025
| std::lock_guard<std::mutex> lock(state.get_mutex()); | ||
| state.get_active_regions().push_back(region); | ||
| } catch (const std::exception& e) { | ||
| std::cerr << "Error in start_region: " << e.what() << std::endl; |
Contributor
There was a problem hiding this comment.
hmm ... afaik that is not how exceptions are supposed to be used ... especially since you are not handling the exception but just printing and not rethrowing. So this would not lead to an abort.
if any of the functions in the try block throw, you are silencing that but also not restoring a valid state so that the program can continue. I would remove the try-catch
JBludau
reviewed
Aug 29, 2025
JBludau
reviewed
Aug 29, 2025
| TimingInfo region; | ||
| region.name = name; | ||
| region.type = type; | ||
| region.start_time = std::chrono::high_resolution_clock::now(); |
Contributor
There was a problem hiding this comment.
when starting, you should take the time at the end and then use it to update the last region in the dqueue. This way you don't measure the construction or the lock
Contributor
There was a problem hiding this comment.
As I am writing this: It of course does not hold for nested regions ... but that is too much for now
ethan-puyaubreau
force-pushed
the
feature/energy-profiler-infrastructure
branch
from
d1bae2d to
049a99f
Compare
…ling in start and end region functions
ethan-puyaubreau
force-pushed
the
feature/energy-profiler-infrastructure
branch
from
049a99f to
6fcf78e
Compare
Contributor
|
A recent reference with related work on rocm: |
Contributor
Thanks! |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
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.
This PR introduces the foundational infrastructure for energy profiling tools in Kokkos:
Features:
TimingInfostructure and region trackingEnergyProfilerStatesingleton for managing active/completed timing regionstiming_exportmodule for exporting timing data to CSV files with summary statisticsImplementation:
kp_energy_profiler- Core profiling functionalitytiming_utils.hpp/cpp- State management and helper functionstiming_export.hpp/cpp- CSV export and summary generationArchitecture:
This infrastructure provides a clean separation between timing collection, state management, and data export, making it easy for future energy monitoring providers to integrate their functionality. The design supports both synchronous and asynchronous profiling patterns (if combined with #300).