> I'm testing the total processing time of recon-all -all using -openmp > 4,6,8,12 . > The runs with 4 and 6 threads took almost the same amount of time. > The runs with 8 and 12 threads took almost the same amount of time. > > (1) Is the work divided evenly between the threads (mri_ca_register, > mri_en_register)? Or is 4 or 8 preferred and 6 and 12 don't buy you > anything?
I can verify that the gain in processing time due to additional threads falls off rapidly with very little gain after 4. I dont know the exact times you got from your tests, and I havent done a time analysis in awhile, but we've never noticed a correlation preferring 4 and 8 threads over 6 and 12. However its an interesting result and could very well be the case. > (2) Is there a sync point in the software so that all the "other" > threads wait for the slowest one to complete. I dont do much of the openmp programming within freesurfer (only for debugging purposes) but as far as I can tell all the openmp relevant code blocks occur at for-loop where threads are all created and diverge simultaneously and then sync and at the same time at the conclusion of the for-loop. If you have an 8-12 processor machine and are looking to reduce your runtimes you can take advantage of the fact that the left and right hemispheres can be processed independently during the autorecon2 stage. You could write a custom script along the lines of: recon-all -s subj -autorecon1 recon-all -s subj -autorecon2-volonly recon-all -s subj -autorecon2-perhemi -hemi rh -log recon-all-hemi rh.log -notify rh-done.log -openmp 4 & recon-all -s subj -autorecon2-perhemi -hemi lh -log recon-all-hemi-lh.log -notify lh-done.log -openmp 4 & while (rh-done.log AND lh-done.log do not both exist) do sleep 1 end loop recon-all -s -autorecon3 > > Also, I tried a run with -use-gpu. > I had to add a directory to LD_LIBRARY_PATH or I get an error on failure > to find one of the libcuda's > That is now ok but I get the following: > > Testing for CUDA device: > ERROR: Unable to acquire a CUDA device! > nvcc: NVIDIA (R) Cuda compiler driver > Copyright (c) 2005-2012 NVIDIA Corporation > Built on Fri_Sep_21_17:28:58_PDT_2012 > Cuda compilation tools, release 5.0, V0.2.1221 > > Acquiring CUDA device > Using default device > Linux comet-30-08.sdsc.edu 3.10.73-1.el6.elrepo.x86_64 #1 SMP Thu Mar 26 > 16:28:30 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux > > recon-all -s 173_1gpu exited with ERRORS at Thu Apr 30 09:17:42 PDT > 2015_PATH but then I get the following error: > > Any thoughts would be welcome. > > Thanks, > Sorry but weve completely abandoned all support of CUDA in favor of openmp. That said, people successfully have and still do use cuda with freesurfer v5.3. Assuming you have a cuda device compatible with the cuda libs shipped with freesurfer it should simply work without you having to modify LD_LIBRARY_PATH, but perhaps someone who has had success in this relm can chime in. _______________________________________________ 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.