You should also know that the memory management during openmp  mri_em_register execution is not optimal (as found by the HCP group. If you are oversubscribing your processors (ie, have 20 cpus, but run 3 jobs each with 8 cpus), then mri_em_register will slow way down. This appears to be due to some caching issues. I'll change recon-all to allow open mp to be disabled during during mri_em_register, but you should be aware of the problem.

Thank you - this is very useful!

On Tue, May 2, 2017 at 12:05 PM, Bruce Fischl <fischl@nmr.mgh.harvard.edu> wrote:

Hi Chris

we have found an almost linear speed improvement up to 4, then it starts to fall off, with not much at all after 8.

cheers
Bruce

On Tue, 2 May 2017, Chris Gorgolewski wrote:

Hi,
We are running freesurfer as part of a bigger pipelines with other steps
that can be performed in parallel to freesurfer reconstruction. So far we
have set the openmp flag to the number of all available cores. However, our
experience with ANTs and AFNI which also capitalize on the OpenMP
parallelization is that there is little benefit of using more than 8-10
cores (even if more are available). Does this also apply to FreeSurfer? Does
anyone have done some benchmarking of this?

Thanks in advance for your help.

Best,
Chris

_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer