cellinfo
/
iprbench
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

improved usecase file hierarchy to accomodate multiple uses cases

This commit is contained in:
Guillaume Raffy 2024-09-27 23:53:24 +02:00
parent 0693b2c948
commit c4732fee87
4 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@ -3,7 +3,7 @@ a tool to benchmark a git cmake application using embarassingly parallel runs
`starbench` is a tool designed to build and test the performance of an application versioned in a `git` repository and using the `cmake` build system. `starbench` is a tool designed to build and test the performance of an application versioned in a `git` repository and using the `cmake` build system.
In order to measure the performance of the code in *hpc* (high performance computing) environment, `starbench` is designed to make all the cores busy. For this, it uses the same technique as in `hpl`'s `stardgemm` test (that's where the 'star' prefix comes from): the same code is run on each `CPU` core. This way, we performances measures are expected to be more realistic, as the cores won't benefit from the unrealistic boost provided by the memory cache of unued cores. In order to measure the performance of the code in *hpc* (high performance computing) environment, `starbench` is designed to make all the cores busy. For this, it uses the same technique as in `hpl`'s `stardgemm` test (that's where the 'star' prefix comes from): the same code is run on each `CPU` core. This way, we performances measures are expected to be more realistic, as the cores won't benefit from the unrealistic boost provided by the memory cache of unused cores.
If the user provides: If the user provides:
- the `url` of the repository - the `url` of the repository
@ -16,7 +16,7 @@ then `starbench` will do the rest:
2. checkout the requested version 2. checkout the requested version
3. configure the build 3. configure the build
4. build the code 4. build the code
5. run the becnhmark command for each core 5. run the benchmark command for each core
6. output the average duration of the benchmark 6. output the average duration of the benchmark
## example ## example

0
usecases/ipr/hibench-on-physix.sh → usecases/ipr/hibench/hibench-on-physix.sh
View File

0
usecases/ipr/readme.md → usecases/ipr/hibench/readme.md
View File

2
usecases/ipr/starbench-template.job → usecases/ipr/hibench/starbench-template.job
View File

@ -80,7 +80,7 @@ else
then then
# TMPDIR will be deleted by sge at the end of the job. Backup data for investigation # TMPDIR will be deleted by sge at the end of the job. Backup data for investigation
backup_dir="/opt/ipr/cluster/work.local/$(whoami)/${JOB_ID}" backup_dir="/opt/ipr/cluster/work.local/$(whoami)/${JOB_ID}"
echo "moving ${output_dir} to ${backup_dir} to that it doesn't get deleted by sge at the end of the job. This way, data gets a chance to be investagated then manually deleted." echo "moving ${output_dir} to ${backup_dir} to that it doesn't get deleted by sge at the end of the job. This way, data gets a chance to be investigated then manually deleted."
mv "${output_dir}" "${backup_dir}" mv "${output_dir}" "${backup_dir}"
fi fi
echo "the command ${command} failed... the output data dir (${output_dir}) is expected to be cleaned up manually after investigation" echo "the command ${command} failed... the output data dir (${output_dir}) is expected to be cleaned up manually after investigation"