Gilles Gouaillardet <gil...@rist.or.jp> writes: > clock_gettime() has a higher precision than gettimeofday(), though it > likely has > a lower precision and higher overhead than opal_sys_timer_get_cycles()
Do you mean OMPI actually uses cycles for timing somewhere? The precision of that would be irrelevant, when it's typically only accurate to within a factor of two or three. > my point was, and iirc, opal_sys_timer_get_cycles() on linux is local > to a given core, > and hence not suitable for MPI since a task might migrate from one > core to an other, > or it might be multithreaded with threads running on different cores. Is the documentation wrong to say wtime isn't (meant to be) global, then? Timing is obviously another reason to bind cores, given the usual distributed system problems even at the smallest relevant scale. Anyhow, the lesson seems to be that you shouldn't use mpi_wtime if you need decent precision or realistic mpi_wtick across implementations. > Cheers, > > Gilles > > On 4/6/2016 11:15 PM, Dave Love wrote: >> Gilles Gouaillardet <gilles.gouaillar...@gmail.com> writes: >> >>> Dave, >>> >>> fwiw, on v1.10, we likely use the number of cycles / cpu freq. >> That would be a horribly broken means of timing. gettimeofday is >> actually called under mpi_wtime, as ompi_info claims. >> >>> see opal_sys_timer_get_cycles in >>> https://github.com/open-mpi/ompi-release/blob/v1.10/opal/include/opal/sys/amd64/timer.h >>> >>> I cannot remember whether this is a monotonic timer. >>> (e.g. MPI_Wtime() invoked on a given cpu is always lower or equal to >>> MPI_Wtime() invoked later and on *any* cpu) >> That's global, not monotonic. MPI_Wtime(1) says it isn't necessarily >> global in OMPI, but it has to be monotonic as I understand it. >> >>> that could be the reason why we moved to clock_gettime() in master. >> The reason to use clock_gettime is higher precision. (I looked into >> this after numbers from a test didn't make much sense.)
