2,684
edits
Performance: Difference between revisions
→Considerations
(Created page with "== Considerations == 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 CO...") |
|||
| Line 5: | Line 5: | ||
# XDS scales well (i.e. the wallclock time for data processing goes down when the number of available cores is increased) in the COLSPOT, IDXREF, INTEGRATE and CORRECT steps when using the [http://www.mpimf-heidelberg.mpg.de/~kabsch/xds/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. | # XDS scales well (i.e. the wallclock time for data processing goes down when the number of available cores is increased) in the COLSPOT, IDXREF, INTEGRATE and CORRECT steps when using the [http://www.mpimf-heidelberg.mpg.de/~kabsch/xds/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. | ||
# the program scales very well in the COLSPOT and INTEGRATE steps when using the [http://www.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/xds_parameters.html#MAXIMUM_NUMBER_OF_JOBS= MAXIMUM_NUMBER_OF_JOBS] keyword. This triggers a shell-level parallelization. | # the program scales very well in the COLSPOT and INTEGRATE steps when using the [http://www.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/xds_parameters.html#MAXIMUM_NUMBER_OF_JOBS= MAXIMUM_NUMBER_OF_JOBS] keyword. This triggers a shell-level parallelization. | ||
# combining these both keywords gives the highest performance in my experience (see [[ | # combining these both keywords gives the highest performance in my experience (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. | ||
# some overcommitting of resources (i.e. MAXIMUM_NUMBER_OF_PROCESSORS * MAXIMUM_NUMBER_OF_JOBS > number of cores) is beneficial; you'll have to play with these two parameters. | # some overcommitting of resources (i.e. MAXIMUM_NUMBER_OF_PROCESSORS * MAXIMUM_NUMBER_OF_JOBS > number of cores) is beneficial; you'll have to play with these two parameters. | ||
# the next thing to consider is [http://www.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/xds_parameters.html#DELPHI= DELPHI] together with [http://www.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/xds_parameters.html#OSCILLATION_RANGE= OSCILLATION_RANGE]: if DELPHI 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 (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. | # the next thing to consider is [http://www.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/xds_parameters.html#DELPHI= DELPHI] together with [http://www.mpimf-heidelberg.mpg.de/~kabsch/xds/html_doc/xds_parameters.html#OSCILLATION_RANGE= OSCILLATION_RANGE]: if DELPHI 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 (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. | ||