2,684
edits
Performance: Difference between revisions
→General considerations
| (12 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== | == General considerations == | ||
In the order of effect: | In the order of effect: | ||
# XDS scales well (i.e. the wallclock time for data processing goes down when the number of available cores is increased) in the INIT, COLSPOT, IDXREF, INTEGRATE and CORRECT steps when using the [http:// | # XDS scales well (i.e. the wallclock time for data processing goes down when the number of available cores is increased) in the INIT, COLSPOT, IDXREF, INTEGRATE and CORRECT steps when using the [http://xds.mpimf-heidelberg.mpg.de/html_doc/xds_parameters.html#MAXIMUM_NUMBER_OF_PROCESSORS= MAXIMUM_NUMBER_OF_PROCESSORS] keyword. This triggers program-level parallelization, using [http://www.openmp.org OpenMP] threads. IDXREF and CORRECT have a significant serial part, for example due to I/O. | ||
# the program scales very well in the COLSPOT and INTEGRATE steps when using the [http:// | # the program scales very well in the COLSPOT and INTEGRATE steps when using the [http://xds.mpimf-heidelberg.mpg.de/html_doc/xds_parameters.html#MAXIMUM_NUMBER_OF_JOBS= MAXIMUM_NUMBER_OF_JOBS] keyword. This triggers a shell-level parallelisation and results in individual processes run by the operating system. There is a slight penalty associated with high values of MAXIMUM_NUMBER_OF_JOBS= : | ||
#*in INTEGRATE, geometry refinement results are not transferred between JOBs: see [[Pathologies]]; | #*in INTEGRATE, geometry refinement results are not transferred between JOBs: see [[Pathologies]]; | ||
#*in COLSPOT, the phi values at the borders between JOBs are less accurate (in particular if the mosaicity is high), and the same reflection may be listed twice in SPOT.XDS if it extends over the border between JOBs. The latter effect may be mitigated by having as many SPOT_RANGEs as JOBs, and leaving gaps between the SPOT_RANGEs; see [[Problems#IDXREF_produces_too_long_axes]]. | #*in COLSPOT, the phi values at the borders between JOBs are less accurate (in particular if the mosaicity is high), and the same reflection may be listed twice in SPOT.XDS if it extends over the border between JOBs. The latter effect may be mitigated by having as many SPOT_RANGEs as JOBs, and leaving gaps between the SPOT_RANGEs; see [[Problems#IDXREF_produces_too_long_axes]]. | ||
# combining these two keywords gives the highest performance | # combining these two keywords gives the highest performance (see [[2VB1#XDS_processing]] for an example). As a rough guide, I'd choose them to be approximately equal; an even number for MAXIMUM_NUMBER_OF_PROCESSORS should be chosen because that fits better with usual hardware. If in doubt, use a lower number for MAXIMUM_NUMBER_OF_JOBS than for MAXIMUM_NUMBER_OF_PROCESSORS. Since 2017, XDS has an automatic feature that divides up the available cores into JOBS (operating system processes) running with multiple cores each. You use this automatic feature when you run <code>xds_par</code>, and don't specify MAXIMUM_NUMBER_OF_JOBS. | ||
# NUMBER_OF_IMAGES_IN_CACHE avoids repeated (3-fold) reading of data frames in the INTEGRATE task during processing of a batch of frames. This comes at the expense of memory (RAM) and is discussed in [[Eiger]]. The default is DELPHI/OSCILLATION_RANGE+1 and is usually adequate. Only on low-memory systems (e.g a 8GB RAM machine for processing Eiger 16M data collected with 0.1° oscillation range, at DELPHI=5 and MAXIMUM_NUMBER_OF_JOBS=1) should this be set to 0, to conserve memory and avoid slow processing due to thrashing, or even killed XDS processes. If the cache size of a process exceeds 8GB, XDS will print a warning, and in that case the user has to explicitly include a NUMBER_OF_IMAGES_IN_CACHE=<desired number> line in XDS.INP, to confirm that actually so much memory should be used. | # NUMBER_OF_IMAGES_IN_CACHE avoids repeated (3-fold) reading of data frames in the INTEGRATE task during processing of a batch of frames. This comes at the expense of memory (RAM) and is discussed in [[Eiger]]. The default is DELPHI/OSCILLATION_RANGE+1 and is usually adequate. Only on low-memory systems (e.g a 8GB RAM machine for processing Eiger 16M data collected with 0.1° oscillation range, at DELPHI=5 and MAXIMUM_NUMBER_OF_JOBS=1) should this be set to 0, to conserve memory and avoid slow processing due to thrashing, or even killed XDS processes. If the cache size of a process exceeds 8GB, XDS will print a warning, and in that case the user has to explicitly include a NUMBER_OF_IMAGES_IN_CACHE=<desired number> line in XDS.INP, to confirm that actually so much memory should be used. '''Typically, you don't specify NUMBER_OF_IMAGES_IN_CACHE'''. | ||
# XDS with the MAXIMUM_NUMBER_OF_JOBS and CLUSTER_NODES keywords can use [[Performance#Cluster|several machines]]. This requires some setup as explained at the bottom of [http://xds.mpimf-heidelberg.mpg.de/html_doc/downloading.html]. | |||
# XDS with the MAXIMUM_NUMBER_OF_JOBS | |||
# Hyperthreading (SMT), if available, is often beneficial. A "virtual" core has only about 20% performance of a "physical" core but it comes at no cost - you just have to switch it on in the BIOS of the machine. | # Hyperthreading (SMT), if available, is often beneficial. A "virtual" core has only about 20% performance of a "physical" core but it comes at no cost - you just have to switch it on in the BIOS of the machine. | ||
# some overcommitting of resources (i.e. MAXIMUM_NUMBER_OF_PROCESSORS * MAXIMUM_NUMBER_OF_JOBS > number of cores) may be beneficial; you'll have to play with these two parameters since this depends on the actual hardware. If MAXIMUM_NUMBER_OF_PROCESSORS * MAXIMUM_NUMBER_OF_JOBS is >4096 (the default in RHEL), you may have to adjust the maxproc limit of your shell; in bash: <code>ulimit -u unlimited</code>. | |||
# the next thing to consider is [http://xds.mpimf-heidelberg.mpg.de/html_doc/xds_parameters.html#DELPHI= DELPHI] together with [http://xds.mpimf-heidelberg.mpg.de/html_doc/xds_parameters.html#OSCILLATION_RANGE= OSCILLATION_RANGE]: if DELPHI (the rotation range of a ''batch'' of frames) is an integer multiple of MAXIMUM_NUMBER_OF_PROCESSORS * OSCILLATION_RANGE that would be good because it nicely balances the usage of the threads. For this purpose, you may want to change (if possible, raise) the value of DELPHI (default is 5 degrees). If you are doing fine-slicing then mis-balancing of threads is not an issue - but for those users who want to collect 1° frames (which I think is not the best way nowadays ...) it should be a consideration. Additional consideration: the total number of frames should be an integer multiple of the intended number of frames in a batch. Example: 360 frames of 0.5° can be processed on a 8-core machine optimally by specifying DELPHI=4, since then there are 8 frames in a batch and the complete dataset has 45 batches. For weak data one should consider raising DELPHI to 12; that would give 15 batches. A trick: if you want to use DELPHI=8 in this situation then just specify DATA_RANGE=1 368 (pretending 23 batches of 8°) instead of DATA_RANGE=1 360 . XDS will complain about the missing 8 frames, but that has no adverse effects except that no FRAME.cbf will be produced. All of this doesn't matter for a single dataset, but for mass processing of datasets it does make a difference. | |||
# performance-wise, I/O also plays a role because as soon as you run 24 or so processes, a single Gigabit ethernet connection may be limiting. OTOH shell-level parallelization smoothes the load. With BUILTs of XDS before 20191211, you could experiment with an environment variable FORT_BUFFERED that when set to TRUE (in ~/.bashrc or better systemwide, with <code>export FORT_BUFFERED=TRUE</code>), will result in faster I/O. Attention: on some installations this has resulted in XDS crashes, so if you get crashes with error message <code>forrtl: severe (67): input statement requires too much data</code> then don't use this option! Since BUILT=20191211, a new version of the ifort compiler is used which should fix the underlying compiler bug. This and later BUILTs employ the option -assume buffered_io, and the environment variable is no longer needed for fast I/O. | |||
# REFINE(INTEGRATE)= ! (empty list) makes INTEGRATE go much faster through the frames, since frames are processed less often when analyzing a batch of frames, and no geometry refinement takes place. TRUSTED_REGION=0 X results in fast processing if X is less than 1.4142 because that reduces the number of pixels of a rectangular detector that will be evaluated; X should of course be chosen such that it does not result in omission of useful data. For fast processing, the defaults for NUMBER_OF_PROFILE_GRID_POINTS_ALONG_ALPHA/BETA and NUMBER_OF_PROFILE_GRID_POINTS_ALONG_GAMMA should be used. | |||
== Cluster == | == Cluster == | ||
If a cluster of computers is available that allow login | If a cluster of computers is available that allow login with <code>ssh</code> without asking for a password, and that have NFS-mounted the relevant directories under the same paths, one can use the [http://xds.mpimf-heidelberg.mpg.de/html_doc/xds_parameters.html#CLUSTER_NODES= CLUSTER_NODES=] keyword in XDS.INP. Attention: if <code>CLUSTER_NODES=a b c</code> then task 1 will run on node b, task 2 on node c, and task 3 on node a. This is due to the logic in the current (BUILT=20191015) version of <code>forkxds</code> (part of XDS package). | ||
If the other computers are not reachable by <code>ssh</code>, but coupled with a batch queueing system, then the forkxds script of the XDS distribution has to be modified: the node names are not relevant, and the <code>ssh</code> invocation has to be replaced by a <code>qsub</code> invocation | If the other computers are not reachable by <code>ssh</code>, but coupled with a batch queueing system, then the forkxds script of the XDS distribution has to be modified: the node names are not relevant, and the <code>ssh</code> invocation has to be replaced by a <code>qsub</code> invocation - see [[Cluster Installation]]. | ||
== processing compressed data == | == processing compressed data == | ||
| Line 184: | Line 26: | ||
XDS can process data files that were previously compressed with compress (<code>.Z</code>), gzip (<code>.gz</code>), bzip2 (<code>.bz2</code>) or xz (<code>.xz</code>). It does this by on-the-fly decompression to temporary files with standard names (<code>SCRATCH2XXYY.tmp</code>) where XX (XX = 01..99) stands for the "JOB" and YY (YY = 01..99) for the thread number that produces the temporary file. | XDS can process data files that were previously compressed with compress (<code>.Z</code>), gzip (<code>.gz</code>), bzip2 (<code>.bz2</code>) or xz (<code>.xz</code>). It does this by on-the-fly decompression to temporary files with standard names (<code>SCRATCH2XXYY.tmp</code>) where XX (XX = 01..99) stands for the "JOB" and YY (YY = 01..99) for the thread number that produces the temporary file. | ||
Compression saves a lot of disk space, but decompression | Compression saves a lot of disk space, but decompression may be time-consuming in terms of CPU and I/O. The penalty associated with decompression can be mitigated by | ||
* using a [http://xds.mpimf-heidelberg.mpg.de/html_doc/xds_parameters.html#LIB= LIB=] plugin that saves the I/O, and overhead of running an external program. This exists for gzip-compressed CBF files; see [[LIB#Existing_implementations]]. | |||
* (Linux only) using symlinks pointing to /dev/shm which results in <code>SCRATCH2XXYY.tmp</code> being written to RAM instead of (network) disk. A script (typically called <code>mklinks</code>) achieving this is | * (Linux only) using symlinks pointing to /dev/shm which results in <code>SCRATCH2XXYY.tmp</code> being written to RAM instead of (network) disk. A script (typically called <code>mklinks</code>) achieving this is | ||
<pre> | <pre> | ||
| Line 221: | Line 64: | ||
== Linux kernel setting == | == Linux kernel setting == | ||
cat /sys/kernel/mm/redhat_transparent_hugepage/enabled | cat /sys/kernel/mm/redhat_transparent_hugepage/enabled | ||
on RHEL6, and | |||
cat /sys/kernel/mm/transparent_hugepage/enabled | cat /sys/kernel/mm/transparent_hugepage/enabled | ||
on RHEL7, respectively, | |||
should show <code>always</code>, not <code>never</code> to be active (the active setting is bracketed). | should show <code>always</code>, not <code>never</code> to be active (the active setting is bracketed). | ||