From f3b4d087c8d82033df34d02598d1022d0cf9a53d Mon Sep 17 00:00:00 2001
From: janEbert <janpublicebert@posteo.net>
Date: Thu, 6 Mar 2025 10:11:06 +0100
Subject: [PATCH] Explain number of CPUs per task

---
 README.md | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/README.md b/README.md
index e8ec00f..d47b479 100644
--- a/README.md
+++ b/README.md
@@ -119,9 +119,11 @@ It can be a good idea to use all available CPUs except one, which is
 kept for the main process.
 
 For example: in our example `sbatch` script for JUWELS Booster, we
-select 12 CPUs per task. We can then pass `--train-num-workers=8
---valid-num-workers=3`. With 8 + 3 = 11 workers in total, we leave one
-CPU for our main process.
+select 12 CPUs per task. (We have one task per GPU per node; JUWELS
+Booster has 48 CPUs and 4 GPUs per node. With the according 4 tasks
+per node, we get 48 ÷ 4 = 12 CPUs per task.) We can then pass
+`--train-num-workers=8 --valid-num-workers=3`. With 8 + 3 = 11 workers
+in total, we leave one CPU for our main process.
 
 ### Launching the processes
 
-- 
GitLab