From 68d842fb39846c512ed072c209e9a9a69b2980a1 Mon Sep 17 00:00:00 2001 From: Han Lu <11597940+ErbB4@users.noreply.github.com> Date: Tue, 30 Jul 2024 08:56:12 +0200 Subject: [PATCH] type setting (#2321) --- doc/concepts/hardware.rst | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/doc/concepts/hardware.rst b/doc/concepts/hardware.rst index 9a015aeef6..39973c97cf 100644 --- a/doc/concepts/hardware.rst +++ b/doc/concepts/hardware.rst @@ -20,20 +20,19 @@ An *allocation* enumerates the computational resources to be used for a simulation, typically a subset of the resources available on a physical hardware node. It also contains flags to enable thread and process `affinity `_. When asked to set affinity, -Arbor will try to maximize the use of the available resources, i.e. it will +Arbor will try to maximize the use of the available resources, i.e., it will spread out processes and threads such that each gets a maximal share of compute -units and cache. Existing affinity settings will honoured, so setting it for -processes while an external mechanism (e.g. SLURM or OpenMPI) does the same is -ill advised. Threads can not be managed externally, thus requesting thread +units and cache. Existing affinity settings will be honoured, so setting it for processes while an external mechanism (e.g., SLURM or OpenMPI) does the same is +ill-advised. Threads can not be managed externally, thus requesting thread binding is generally safe and may yield significant performance improvements for CPU-only simulations and/or the model build phase. Affinity requires `hwloc `_ to be found during build time. New users can find using contexts a little verbose. The design is very deliberate, to allow fine-grained control over which computational resources an -Arbor simulation should use. As a result Arbor is much easier to integrate into +Arbor simulation should use. As a result, Arbor is much easier to integrate into workflows that run multiple applications or libraries on the same node, because -Arbor has a direct API for using on node resources (threads and GPU) and +Arbor has a direct API for using on-node resources (threads and GPU) and distributed resources (MPI) that have been partitioned between applications/libraries.