Conversation
Summary of ChangesHello @BenWibking, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the simulation's diagnostic capabilities by adding functionality to record the wall-clock time taken for each computational cycle. This data is written to a user-configurable text file in a buffered manner, providing a valuable tool for identifying and analyzing performance bottlenecks, particularly in high-performance computing environments. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces a valuable feature for performance analysis by outputting per-cycle timing data to a file. The implementation is straightforward, using a buffered approach to manage I/O. My review includes two main suggestions to enhance the robustness of this new functionality. First, to handle simulation restarts correctly, the timing file should be opened in append mode to avoid losing historical data. Second, I've recommended adding error handling to the file-writing process to gracefully manage potential I/O issues. These improvements will ensure the feature is reliable for large-scale and long-running simulations.
| if (printCycleTiming_ == 1 && amrex::ParallelDescriptor::IOProcessor()) { | ||
| cycle_timing_file.open(cycleTimingFile_, std::ios::out); | ||
| if (cycle_timing_file.is_open()) { | ||
| cycle_timing_file << "# cycle elapsed_sec\n"; | ||
| cycle_timing_buffer.reserve(static_cast<size_t>(cycle_timing_flush_interval)); | ||
| } else { | ||
| amrex::Print() << "[WARNING] Failed to open cycle timing file '" << cycleTimingFile_ << "' for writing.\n"; | ||
| } | ||
| } |
There was a problem hiding this comment.
The current implementation opens the cycle timing file in truncation mode (std::ios::out), which overwrites the file's contents upon simulation restart. This results in the loss of timing history from the previous run, which is critical for performance analysis across restarts. To preserve the history, the file should be opened in append mode when restarting a simulation.
if (printCycleTiming_ == 1 && amrex::ParallelDescriptor::IOProcessor()) {
const bool is_restarting = !restart_chkfile.empty();
auto open_mode = is_restarting ? std::ios::app : std::ios::out;
cycle_timing_file.open(cycleTimingFile_, open_mode);
if (cycle_timing_file.is_open()) {
if (!is_restarting) {
cycle_timing_file << "# cycle elapsed_sec\n";
}
cycle_timing_buffer.reserve(static_cast<size_t>(cycle_timing_flush_interval));
} else {
amrex::Print() << "[WARNING] Failed to open cycle timing file '" << cycleTimingFile_ << "' for writing.\n";
}
}There was a problem hiding this comment.
This is a good point. I will change it to open in append mode with a restart message, like the history.txt output.
|



Description
This outputs the per-cycle timing to a text file. This is essential for debugging performance issues at scale.
Related issues
N/A
Checklist
Before this pull request can be reviewed, all of these tasks should be completed. Denote completed tasks with an
xinside the square brackets[ ]in the Markdown source below:/azp run.