Dear list,

we are currently planning to migrate our fMRI postprocessing from spm2
to spm5. I (a researcher and spm5 user, no sysadmin) did a couple of
tests,  using a very similar and simple model (1 box-car HRF convolved
regressor + constant) in both spm2 and spm5, 1000 scans. What is really
strange to me is that in spm2 the estimation takes about 30 minutes (2
passes; AR(1) autocorrelation estimation, actual parameter estimation),
whereas in spm5 it took about 4 hours (same 2 passes, output in console
is very similar). Furthermore, CPU load for the spm2 estimation jumped
to almost 90%, whereras for spm5 it hardly exceeded 20%. That all would
be unworkable with more than 10 users. We use a multiprocessor Xeon
Linux server, running debian, and run both spm's in matlab 7 (R2006b).
I did recompile the spm5 (mexa64) binaries on our system, using the
default spm5 makefile in /src (make; make install). The last spm5
patches we applied where updates_573.

Preprocessing in spm5 appeared to be of comparable speed as compared to
spm2.

I have set defaults.stats.maxmem to 2^20 in both spm2 and spm5.

I really can't explain this discrepancy. In the archives someone seemed
to have noticed something similar:
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0610&L=SPM&P=R18235&I=-3&X=09940203E3366DA97F&Y=b.neggers%40umcutrecht.nl

Our problem is different from the batch interface handling slowing 
discussed here:
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0611&L=SPM&P=R37959&I=-3&X=09940203E3366DA97F&Y=b.neggers%40umcutrecht.nl
That seemed to have been caused by file loading in the batch structure,
we do not seem to have that issue.

But that sysadmin was told not to worry since fMRI estimations do take a
lot of time, and "get used to it". But with my tests in mind I am afraid
that something has fundamentally changed in the estimation procedure,
which slows estimation down, be it perhaps on only some systems. I have
thought about the NaN issue affecting Intel processors, which is indeed
thought to slowdown estimation. But I recompiled the binaries.
Furthermore, the processor seems not to be taxed to the full in spm5, 
which one would not expect with NaN problems.
Perhaps spm5 has other file I/O bottlenecks/memory mapping techniques?
Should I still recompile with other gcc settings than default in spm5?
On this page:

http://www.sph.sc.edu/comd/rorden/spm99.html

...you can read about slow spm2 processing on intel CPUs, but nothing is
said if this is dealt with correctly by spm5 makefile/c-code. Should I
change the gcc flags in the spm5 makefile too, or do 64 bit Xeon
processors have no issues anymore with NaN? On the above benchmark site
there is no mention yet of 64 bit procs nor spm5...

Any help would be appreciated!

Cheers,

Bas

-- 
--------------------------------------------------
Dr. S.F.W. Neggers
Division of Brain Research
Rudolf Magnus Institute for Neuroscience
Utrecht University Medical Center

Visiting : Heidelberglaan 100, 3584 CX Utrecht
           Room A.00.1.24
Mail     : Huispost A.01.126, P.O. Box
           3508 GA Utrecht, the Netherlands
Tel      : +31 (0)30 2503386
Fax      : +31 (0)30 2505443
E-mail   : [log in to unmask]
Web      : http://www.fmri.nl/people/bas.html
--------------------------------------------------