[Wien] Wien 2k benchmarks on Apple MacPRO (MacOS X Server10.4.10)

[Gerhard Fecher]

Hi Peter,
I did such a check some times ago for a machine with two XEON, here are the results from some recent tests
(the wall times agree roughly with a fast check using the date command for the total runtime if the 
parallel jobs are started from a shell script):

Results for a machine with 2 singlecore CPU Xeon (HT, 3.8 GHz, 4 GByte RAM), Wien2k 07.3, SUSE 10.0, Kernel 2.6.13-15.8-smp, ifort 10.0.026, mkl 9.1.023:

wall times        job 1   job 2   job 3   job 4   max for 4 jobs (4*1, 2*2, or 1*4 in sequence)           
1 job  1 thread   154.141                         4*154.141 = 10 min 16 sec
2 jobs 1 thread   194.680 195.148                 2*195.148 =  6 min 20 sec
4 jobs 1 thread   406.265 407.657 415.017 415.421 1*415.421 =  6 min 55 sec
                                                  
1 job  2 threads  118.788                         4*118.788 =  7 min 55 sec
2 jobs 2 threads  219.890 219.839                 2*219.890 =  7 min 19 sec
4 jobs 2 threads  416.040 411.024 416.807 409.095 1*415.421 =  6 min 56 sec

One gains about 25% if using 2 threads for a single job, but it seems that it is rather unfavourable to run 4 jobs sequentially with 1 thread. However 1 thread is fine if running 2 (or more jobs) in parallel, whereas 2 threads are fast for running a single job. I think it depends what one needs. If one runs the jobs from batch, one can easily set the OMP_NUM_THREAD number to the "best" value. 
                                                  
Results for a machine with 2 dualcore CPU Xeon 5160 (3 GHz, 8 GByte RAM), Wien2k 07.3, SUSE 10.1, Kernel 2.6.16.53-0.8-smp, ifort 10.0.026, mkl 9.1.023:

wall times        job 1   job 2   job 3   job 4   max for 4 jobs           
1 job  1 thread   112.331                         4*112.331 =  7 min 29 sec

1 job  2 threads   90.815                         4* 90.815 =  6 min  3 sec
                                                 
1 job  4 threads   80.250                         4* 80.250 =  5 min 21 sec

That means the speed is about 30% higher for the larger number of threads. 

On that machine, I was not able to check for more than one job due to a very strange error, the computer switches off
if I try to run two or more jobs in parallel, independent of the number of threads (seems actually to be independent
of the Kernel, ifort and mkl Versions, I tested already several different configurations,
I also could not find any faulty memorychips).
 
Ciao
Gerhard

I also tried static linking on the em64t kernels and it does not produce the segmentation fault anymore,
at least for the test.case, where the 32 bit Linux pthread causes the troubles. (Actually, the results above are for  static linking on the 5160 machine, but the computer switches off by itself independent of static or dynamic linking.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 4162 bytes
Desc: not available
Url : http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20071006/ab4295bd/attachment.bin