Hi, I've noticed recon-all (-all) doesn't really grind my cpu as intensely as it might, which makes me wonder if it might be more I/O limited, which further makes me wonder if I could get any kind of speedup using a tmpfs to store the subject's directory while running recon-all, and then copying the results back to disk when I'm done.
Does anyone know how I/O limited recon-all is (I realize it consists of many tasks, but if even some of them would be significantly sped up by putting their data in memory, it'd be worth my time).
Also, do all recon-all components store their scratch data (if they have it) in the subject directory? or do they go somewhere else (like /tmp or /var)?
Thanks for the help
--Luke Hospadaruk
that's surprising. Most of the time it should be pretty compute-bound.
cheers, Bruce On Thu, 28 May 2009, Luke Robot Hospadaruk wrote:
Hi, I've noticed recon-all (-all) doesn't really grind my cpu as intensely as it might, which makes me wonder if it might be more I/O limited, which further makes me wonder if I could get any kind of speedup using a tmpfs to store the subject's directory while running recon-all, and then copying the results back to disk when I'm done.
Does anyone know how I/O limited recon-all is (I realize it consists of many tasks, but if even some of them would be significantly sped up by putting their data in memory, it'd be worth my time).
Also, do all recon-all components store their scratch data (if they have it) in the subject directory? or do they go somewhere else (like /tmp or /var)?
Thanks for the help
--Luke Hospadaruk _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Hi. I/O is not quite the bounding issue.
I would invest in CPU and them in memory.
cheers ----------------------------------------------------------- Pedro Paulo de M. Oliveira Junior Diretor de Operações Netfilter & SpeedComm Telecom --- Novo Netfilter 3.0 www.Netfilter.com.br
2009/5/28 Luke Robot Hospadaruk hospada1@msu.edu
Hi, I've noticed recon-all (-all) doesn't really grind my cpu as intensely as it might, which makes me wonder if it might be more I/O limited, which further makes me wonder if I could get any kind of speedup using a tmpfs to store the subject's directory while running recon-all, and then copying the results back to disk when I'm done.
Does anyone know how I/O limited recon-all is (I realize it consists of many tasks, but if even some of them would be significantly sped up by putting their data in memory, it'd be worth my time).
Also, do all recon-all components store their scratch data (if they have it) in the subject directory? or do they go somewhere else (like /tmp or /var)?
Thanks for the help
--Luke Hospadaruk _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
What are you using to maeasure the CPU use? Freesurfer is a single threaded application. If you have a multiple CPU/core box, some CPU monitor programs often show a CPU usage of only '25%' on a 4 core box when a single threaded program is running at full CPU use.
On Thu, 28 May 2009, Pedro Paulo de Magalhães Oliveira Junior wrote:
Hi. I/O is not quite the bounding issue.
I would invest in CPU and them in memory.
2009/5/28 Luke Robot Hospadaruk hospada1@msu.edu
Hi, I've noticed recon-all (-all) doesn't really grind my cpu as intensely as it might, which makes me wonder if it might be more I/O limited, which further makes me wonder if I could get any kind of speedup using a tmpfs to store the subject's directory while running recon-all, and then copying the results back to disk when I'm done.
Does anyone know how I/O limited recon-all is (I realize it consists of many tasks, but if even some of them would be significantly sped up by putting their data in memory, it'd be worth my time).
Also, do all recon-all components store their scratch data (if they have it) in the subject directory? or do they go somewhere else (like /tmp or /var)?
freesurfer@nmr.mgh.harvard.edu
-
Bruce Fischl -
Luke Robot Hospadaruk -
Paul Raines -
Pedro Paulo de Magalhães Oliveira Junior