[FLASH-USERS] Details of speedup after restart
Dan Sheeler
sheeler at flash.uchicago.edu
Tue Jun 5 20:54:46 CDT 2007
Does this run have just 64 blocks (4 x 16)? If this is a standard flash
setup with local physics, having less than one block per process probably
will produce weird performance numbers. In a standard run, 2d 8x8 blocks
require very little ram or work per process. Single processes are happy
working on thousands of blocks. Furthermore, work is distributed to the
processors in nothing smaller than block-sized chunks. If your run is a
typical setup, then half of the processes have more-or-less nothing to do
but add communication, and I can imagine that would cause runtime to
fluctuate non-deterministically.
Dan
--
Dan Sheeler
ASC Flash Center
sheeler at flash.uchicago.edu
(773) 834-3236
On Tue, 5 Jun 2007, sanjib gupta wrote:
> Hi,
>
> I am attaching 2 log files - the initial run on 128 processors, then
> immediately killing the job and restarting from the first checkpoint file
> "hc-rt-hdf5_chk_0000"
> notice about 4 timesteps per second initially, then ~30 timesteps/sec after
> restart.
>
> On 64 processors I noticed the gain was higher , but my resolution was lower
> (half the number of nblocky, same nblockx, this is a 2D run)- sorry did not
> keep the logfiles.
>
> However this "gain" cannot be predicted......sometimes I don't get it on the
> first restart, so I restart a couple of times!
> As you'all can guess, this plays havoc with any benchmarking efforts
> .......and we do intend to showcase our results from FLASH soon ... :-)
>
> We compile with intel fortran 9.1.033 and openmpi 1.1 on a linux cluster
> ....and hdf5 version 1.6.5 ......Makefile.h is attached.
> Architecture - 64 bit AMD Opteron
> running FC3 linux + BProcV4 (cluster OS) with kernel = 2.6.14
>
> Thanks much for your help/insight/suggestions,
> Sanjib.
>
More information about the flash-users
mailing list