On Thu, Apr 7, 2016 at 4:19 PM, Jeff Hammond wrote:
>
>
> On Thu, Apr 7, 2016 at 9:28 AM, Dave Love wrote:
>
>> ...
>> Anyhow, the lesson seems to be that you shouldn't use mpi_wtime if you
>> need decent precision or realistic mpi_wtick across implementations.
>>
>> I certainly hope that this i
Hi,
I tried to build openmpi-dev-3793-g896f857 on my machines
(Solaris 10 Sparc, Solaris 10 x86_64, and openSUSE Linux
12.1 x86_64) with gcc-5.2.0 and Sun C 5.13. I was successful on
my Linux machine, but I got the following errors on both Solaris
platforms with both compilers. In my opinion one
George Bosilca writes:
>> Other implementations of MPI have very accurate counters.
>>
>
> This might be a discutable topic. A quick survey of some of the MPI
> libraries available on a Linux cluster give the following precision for
> MPI_Wtime implementation :
>
> mpich-3.1.4: wtick = 1.00e-
Dave,
gettimeofday() uses (seconds, microseconds) to represent the time, and
hence, the resolution is hardcoded to 1 microsecond
clock_gettine() uses (seconds, nanoseconds) and hence the resolution is
hard coded to 1 nanosecond.
this is the max resolution, and it could be lower than that depending
George:
Indeed, MPI_Wtick is not always a good measure of the precision of
MPI_Wtime. The way I would measure resolution is to call MPI_Wtime a few
million times.
For example, on Blue Gene/Q, MPI_Wtime was ~220 cycles per call. I don't
remember what MPI_Wtick returned, but I guess it was 1./1.6
MPI_Wtick is not about the precision but about the resolution of the
underlying timer (aka. the best you can hope to get). Thus, the measured
time will certainly be larger, but, and this is almost a certainty, it will
hardly be smaller. As a result, I am doubtful that an MPI implementation
will pro
