KAHIBARO
40.2. Selecting the Number of Threads
Table of Contents
CPU resources
GATE can run simulations in multithreaded mode so that several events are processed at the same time on different CPU cores. Choosing how many threads to use is mainly a resource management problem. Each thread needs CPU time and memory, and you must stay within what your system can provide.
On a typical workstation or laptop, you can check how many logical cores you have with tools like lscpu on Linux, Task Manager on Windows, or Activity Monitor on macOS. Logical cores include hardware threads such as Intel Hyper‑Threading. As a beginner rule, you usually choose a number of threads between half and all of your logical cores.
Each GATE worker thread keeps its own copy of some data, so memory usage increases with the number of threads. If your geometry is complex or uses large voxel phantoms, each additional thread can cost hundreds of megabytes. If the total memory demand is close to your system limit, the operating system will start swapping to disk, which is extremely slow and will harm performance.
Use this rough process to select a safe starting point. First, estimate how much memory your simulation needs in single‑threaded mode by running a short test and watching memory usage. Second, divide your available RAM by that amount to get an upper bound on feasible threads. Finally, clamp that number to at most the number of logical cores. For example, if a single thread uses about 2 GB, and you have 16 GB available and 8 cores, then 16 / 2 = 8 is allowed by memory and by cores, so 8 threads is a reasonable upper limit.
In shared environments like university clusters, never assume you can use all physical cores on a node. The batch system configuration and job submission settings for CPU allocation, covered in the HPC chapter, define how many cores you are allowed to use. Select the number of threads in GATE to match the CPU resources requested in your job script. Using more threads than allocated cores will force many threads to share each core and can hurt performance instead of helping.
Always keep the number of GATE threads less than or equal to both the number of logical CPU cores you are allowed to use and the amount of memory you can safely provide without swapping.
Performance
The main purpose of multithreading in GATE is to reduce wall‑clock time for a fixed number of events. More threads usually means more events processed per second, but only up to a point. When you add too many threads, they start competing for the same physical resources and the performance gain flattens or even degrades.
Performance depends on how much work each event contains. If events are simple, for example a tiny geometry and a monoenergetic beam, the overhead of managing many threads can become comparable to the work itself, so speedup is limited. If events are heavy, for example complex patient geometries or long particle tracks, each thread does more useful work and multithreading scales better.
A practical way to find a good thread count is to run short timing tests with different numbers of threads and measure events per second. For example, test 1, 2, 4, and 8 threads with the same physics, geometry, and number of events, and record the runtime from the log. Plotting or listing the effective speedup often shows a clear point where moving to more threads yields only a small improvement. Choose the smallest thread count near that plateau, to leave some CPU room for the operating system and other tasks.
You must also balance multithreading with input and output. If your simulation writes very large ROOT or image files, disk throughput can become the bottleneck. In that case, increasing threads will not make the simulation faster, because threads will often wait on disk. To improve performance in such cases, you can reduce the amount of data written, for example by disabling unnecessary actors or outputs, or by using coarser dose grids. The detailed strategies for reducing output are covered in the output optimization section of this chapter.
Multithreading can also interact with complex geometries. Deep hierarchies of repeated volumes and large voxelized phantoms make geometry navigation more expensive. More threads then increase the total navigation workload. If performance is poor even with a reasonable thread count, consider simplifying or restructuring your geometry, or using repetition features that GATE and Geant4 handle efficiently. Geometry optimization is treated in a separate section, so here it is enough to remember that thread count cannot compensate for highly inefficient geometry design.
For absolute beginners, a simple and safe strategy is to start with 1 thread to confirm that your simulation runs correctly, then test 2 and 4 threads and compare runtimes. Use the smallest number of threads that gives you most of the available speedup. As you gain experience and work with larger problems, you can invest a bit more time in systematic tests to find the best configuration for your hardware and your specific simulation.
Views: 12