From c4732fee87a6f50cf68aa608a809ed7126bc2cfe Mon Sep 17 00:00:00 2001 From: Guillaume Raffy Date: Fri, 27 Sep 2024 23:53:24 +0200 Subject: [PATCH] improved usecase file hierarchy to accomodate multiple uses cases --- README.md | 4 ++-- usecases/ipr/{ => hibench}/hibench-on-physix.sh | 0 usecases/ipr/{ => hibench}/readme.md | 0 usecases/ipr/{ => hibench}/starbench-template.job | 2 +- 4 files changed, 3 insertions(+), 3 deletions(-) rename usecases/ipr/{ => hibench}/hibench-on-physix.sh (100%) rename usecases/ipr/{ => hibench}/readme.md (100%) rename usecases/ipr/{ => hibench}/starbench-template.job (98%) diff --git a/README.md b/README.md index 8de3fa4..ba03043 100644 --- a/README.md +++ b/README.md @@ -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. -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: - the `url` of the repository @@ -16,7 +16,7 @@ then `starbench` will do the rest: 2. checkout the requested version 3. configure the build 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 ## example diff --git a/usecases/ipr/hibench-on-physix.sh b/usecases/ipr/hibench/hibench-on-physix.sh similarity index 100% rename from usecases/ipr/hibench-on-physix.sh rename to usecases/ipr/hibench/hibench-on-physix.sh diff --git a/usecases/ipr/readme.md b/usecases/ipr/hibench/readme.md similarity index 100% rename from usecases/ipr/readme.md rename to usecases/ipr/hibench/readme.md diff --git a/usecases/ipr/starbench-template.job b/usecases/ipr/hibench/starbench-template.job similarity index 98% rename from usecases/ipr/starbench-template.job rename to usecases/ipr/hibench/starbench-template.job index 9400200..672929e 100644 --- a/usecases/ipr/starbench-template.job +++ b/usecases/ipr/hibench/starbench-template.job @@ -80,7 +80,7 @@ else then # 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}" - 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}" fi echo "the command ${command} failed... the output data dir (${output_dir}) is expected to be cleaned up manually after investigation"