You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When running peaksearch or grid_index_parallel or refine_em there are some multiprocessing options that do not play well with threading. Multiprocessing launches Ncores jobs and each job launches Ncores threads so you end up with (Ncores x Ncores) fighting for resources. OK when there are 2 cores giving 4 tasks, a bit of an overhead with 64*64 = 4096.
Options/issues:
Offer and test a cImageD11.set_num_threads() -> call omp_set_num_threads
Use : dask? joblib? etc replacing multiprocessing to also spread work on a cluster
OAR/SLURM: What is omp_get_max_threads and multiprocessing.cpu_count() versus cores assigned?
Related: add some benchmarking / testing code to verify whether cImageD11 functions are working properly and how they are performing versus thread count.
The text was updated successfully, but these errors were encountered:
jonwright
added a commit
to jonwright/ImageD11
that referenced
this issue
Jan 8, 2020
When running peaksearch or grid_index_parallel or refine_em there are some multiprocessing options that do not play well with threading. Multiprocessing launches Ncores jobs and each job launches Ncores threads so you end up with (Ncores x Ncores) fighting for resources. OK when there are 2 cores giving 4 tasks, a bit of an overhead with 64*64 = 4096.
Options/issues:
Related: add some benchmarking / testing code to verify whether cImageD11 functions are working properly and how they are performing versus thread count.
The text was updated successfully, but these errors were encountered: