This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
> On a separate topic, but related to your post here, how did you do
> the timing? [Especially to so many digits of accuracy. :-) ]
two things to consider:
i) What do I actually (want to) measure?
ii) How accurate can I do that?
Option iA) execution time of the whole program
One could use /usr/bin/time. Simple, but that is not that accurate. If
you do not need microsecond accuracy and measure all the things you
want to compare in the same fashion a run like "/usr/bin/time mpirun
-np X myprog" should perfectly suits your needs.
Option iB) time my 'crunching core' runs
Something in rank0 like
"time1=gettime(); crunch_alot(); time2=gettime(); time_used=time2-time1;"
is much better suited to actually measure only the important parts,
esp. if they can run shortly compared to overall programm execution
time. (this assumes that crunch_alot() has a barrier character, e.g. by
collecting values from all processes at the end)
MPI_Wtime() is generally considered the best way, as it is platform
independent and usually MPI libs try to use the most accurate
measurement method available on every certain platform.
I've just used gettimeofday(), because some of my demo apps are
intended to run independent of MPI. So my accuracy is at most micro
seconds (on some platforms that might be different; e.g. only 10ms-steps).
> [Especially to so many digits of accuracy. :-) ]
By unsuitably using printf("%.9f",time) ;-)
I've just not cleared up that part. (But still the thing
I wanted to demonstrate became quite apparent.)