Skip to content

Conversation

ritvikrao
Copy link
Contributor

Adds ping-ack (with timing) as a converse benchmark

Copy link
Contributor

@lvkale lvkale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a short describing what the benchmark does.

Also.. is any purpose served by having the filename be ping rather than pingack?

@ritvikrao
Copy link
Contributor Author

Please add a short describing what the benchmark does.

Also.. is any purpose served by having the filename be ping rather than pingack?

I changed the file name and added a readme

@ritvikrao ritvikrao requested a review from lvkale September 19, 2025 19:30
Copy link
Contributor

@lvkale lvkale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The readme text needs to be elaborated. (Also, you mean e.g. instead of "i.e." for the result data format. )
I suggest adding: Other than control messages all message sends happen from one process and all receives happen on the other process. This asymmetry is intentional so send related overheads can be separated easily from receive related overheads. This benchmark also exposes any bottlenecks in the message path, such as communication threads, serializing locks, etc. It has also been used to see how wide a processes should be in finegrained apllications (i.e. how many pes per processes.. or alternatively how many processes should one have on one physical node, for good performance).

Added a section explaining the benchmark's purpose and utility.
@ritvikrao
Copy link
Contributor Author

The readme text needs to be elaborated. (Also, you mean e.g. instead of "i.e." for the result data format. ) I suggest adding: Other than control messages all message sends happen from one process and all receives happen on the other process. This asymmetry is intentional so send related overheads can be separated easily from receive related overheads. This benchmark also exposes any bottlenecks in the message path, such as communication threads, serializing locks, etc. It has also been used to see how wide a processes should be in finegrained apllications (i.e. how many pes per processes.. or alternatively how many processes should one have on one physical node, for good performance).

I changed the readme to add this information

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants