¿Se garantiza que gettimeofday () tiene una resolución de microsegundos?

Estoy portando un juego, que fue escrito originalmente para la API Win32, a Linux (bueno, portando el puerto OS X del puerto Win32 a Linux).

Lo he implementado QueryPerformanceCounterdando los uSeconds desde que se inició el proceso:

BOOL QueryPerformanceCounter(LARGE_INTEGER* performanceCount)
{
    gettimeofday(&currentTimeVal, NULL);
    performanceCount->QuadPart = (currentTimeVal.tv_sec - startTimeVal.tv_sec);
    performanceCount->QuadPart *= (1000 * 1000);
    performanceCount->QuadPart += (currentTimeVal.tv_usec - startTimeVal.tv_usec);

    return true;
}

Esto, junto con QueryPerformanceFrequency()dar una constante de 1000000 como frecuencia, funciona bien en mi máquina , dándome una variable de 64 bits que contiene uSecondsdesde el inicio del programa.

Entonces, ¿ es esto portátil? No quiero descubrir que funciona de manera diferente si el kernel se compiló de cierta manera o algo así. Sin embargo, estoy de acuerdo con que no sea portátil a algo que no sea Linux.

Tal vez. Pero tienes problemas mayores. gettimeofday()puede resultar en tiempos incorrectos si hay procesos en su sistema que cambian el temporizador (es decir, ntpd). En un linux "normal", sin embargo, creo que la resolución de gettimeofday()es 10us. Puede saltar hacia adelante y hacia atrás y el tiempo, en consecuencia, en función de los procesos que se ejecutan en su sistema. Esto efectivamente hace que la respuesta a su pregunta no.

Debería buscar clock_gettime(CLOCK_MONOTONIC)intervalos de tiempo. Sufre de varios problemas menores debido a cosas como sistemas de múltiples núcleos y configuraciones de reloj externo.

Además, mire la clock_getres()función.

Temporización de alta resolución y baja sobrecarga para procesadores Intel

Si tiene hardware Intel, aquí le mostramos cómo leer el contador de instrucciones en tiempo real de la CPU. Le dirá el número de ciclos de CPU ejecutados desde que se inició el procesador. Este es probablemente el contador más detallado que puede obtener para medir el rendimiento.

Tenga en cuenta que este es el número de ciclos de CPU. En Linux, puede obtener la velocidad de la CPU de / proc / cpuinfo y dividir para obtener el número de segundos. Convertir esto en un doble es bastante útil.

Cuando ejecuto esto en mi caja, obtengo

11867927879484732
11867927879692217
it took this long to call printf: 207485

Aquí está la guía para desarrolladores de Intel que brinda muchos detalles.

#include <stdio.h>
#include <stdint.h>

inline uint64_t rdtsc() {
    uint32_t lo, hi;
    __asm__ __volatile__ (
      "xorl %%eax, %%eax\n"
      "cpuid\n"
      "rdtsc\n"
      : "=a" (lo), "=d" (hi)
      :
      : "%ebx", "%ecx");
    return (uint64_t)hi << 32 | lo;
}

main()
{
    unsigned long long x;
    unsigned long long y;
    x = rdtsc();
    printf("%lld\n",x);
    y = rdtsc();
    printf("%lld\n",y);
    printf("it took this long to call printf: %lld\n",y-x);
}

@Bernardo:

Debo admitir que la mayor parte de su ejemplo se me pasó por la cabeza. Sin embargo, se compila y parece funcionar. ¿Es esto seguro para los sistemas SMP o SpeedStep?

Esa es una buena pregunta ... Creo que el código está bien. Desde un punto de vista práctico, lo usamos en mi empresa todos los días y ejecutamos una amplia gama de cajas, de 2 a 8 núcleos. Por supuesto, YMMV, etc., pero parece ser un método de sincronización confiable y de bajo costo (porque no hace un cambio de contexto al espacio del sistema).

Generalmente, cómo funciona es:

• declare el bloque de código como ensamblador (y volátil, por lo que el optimizador lo dejará en paz).
• ejecutar la instrucción CPUID. Además de obtener información de la CPU (con la que no hacemos nada), sincroniza el búfer de ejecución de la CPU para que los tiempos no se vean afectados por la ejecución fuera de orden.
• ejecutar la ejecución de rdtsc (lectura de marca de tiempo). Obtiene el número de ciclos de máquina ejecutados desde que se reinició el procesador. Este es un valor de 64 bits, por lo que con las velocidades de CPU actuales, se ajustará aproximadamente cada 194 años. Curiosamente, en la referencia original de Pentium, señalan que se envuelve aproximadamente cada 5800 años.
• el último par de líneas almacenan los valores de los registros en las variables hi y lo, y lo colocan en el valor de retorno de 64 bits.

Notas específicas:

• La ejecución fuera de orden puede causar resultados incorrectos, por lo que ejecutamos la instrucción "cpuid" que además de darle alguna información sobre la CPU también sincroniza cualquier ejecución de instrucción fuera de orden.

• La mayoría de los sistemas operativos sincronizan los contadores en las CPU cuando se inician, por lo que la respuesta es buena en un par de nanosegundos.

• El comentario de hibernación probablemente sea cierto, pero en la práctica probablemente no le importen los tiempos a través de los límites de hibernación.

• con respecto al paso de velocidad: las CPU Intel más nuevas compensan los cambios de velocidad y devuelven un recuento ajustado. Hice un escaneo rápido en algunas de las cajas en nuestra red y encontré solo una caja que no lo tenía: un Pentium 3 que ejecutaba un servidor de base de datos antiguo. (estas son cajas de Linux, así que verifiqué con: grep constant_tsc / proc / cpuinfo)

• No estoy seguro acerca de las CPU de AMD, somos principalmente una tienda de Intel, aunque sé que algunos de nuestros gurús de sistemas de bajo nivel hicieron una evaluación de AMD.

Espero que esto satisfaga su curiosidad, es un área de programación interesante y (en mi humilde opinión) poco estudiada. ¿Sabes cuando Jeff y Joel hablaban sobre si un programador debería conocer C? Les gritaba: "Olvídense de ese material C de alto nivel ... ¡ensamblador es lo que debe aprender si quiere saber qué está haciendo la computadora!"

Puede estar interesado en las preguntas frecuentes de Linux paraclock_gettime(CLOCK_REALTIME)

Wine está usando gettimeofday () para implementar QueryPerformanceCounter () y se sabe que hace que muchos juegos de Windows funcionen en Linux y Mac.

Inicia http://source.winehq.org/source/dlls/kernel32/cpu.c#L312

conduce a http://source.winehq.org/source/dlls/ntdll/time.c#L448

Entonces dice microsegundos explícitamente, pero dice que la resolución del reloj del sistema no está especificada. Supongo que la resolución en este contexto significa ¿cómo se incrementará la cantidad más pequeña?

La estructura de datos se define como microsegundos como unidad de medida, pero eso no significa que el reloj o el sistema operativo sea realmente capaz de medir eso con precisión.

Como han sugerido otras personas, gettimeofday()es malo porque fijar la hora puede hacer que el reloj se desvíe y desvíe el cálculo. clock_gettime(CLOCK_MONOTONIC)es lo que quieres y clock_getres()te dirá la precisión de tu reloj.

La resolución real de gettimeofday () depende de la arquitectura del hardware. Los procesadores Intel y las máquinas SPARC ofrecen temporizadores de alta resolución que miden microsegundos. Otras arquitecturas de hardware recurren al temporizador del sistema, que normalmente se establece en 100 Hz. En tales casos, la resolución de tiempo será menos precisa.

Obtuve esta respuesta de Medición de tiempo y temporizadores de alta resolución, Parte I

Esta respuesta menciona problemas con el ajuste del reloj. Tanto sus problemas de garantía de unidades de ticks como los problemas de ajuste de tiempo se resuelven en C ++ 11 con la <chrono>biblioteca.

Se std::chrono::steady_clockgarantiza que el reloj no se ajustará y, además, avanzará a una velocidad constante en relación con el tiempo real, por lo que tecnologías como SpeedStep no deben afectarlo.

Puede obtener unidades con seguridad de tipos convirtiendo a una de las std::chrono::durationespecializaciones, como std::chrono::microseconds. Con este tipo no hay ambigüedad sobre las unidades utilizadas por el valor de tick. Sin embargo, tenga en cuenta que el reloj no necesariamente tiene esta resolución. Puede convertir una duración a attosegundos sin tener un reloj tan preciso.

Por mi experiencia y por lo que he leído en Internet, la respuesta es "No", no está garantizado. Depende de la velocidad de la CPU, el sistema operativo, el sabor de Linux, etc.

La lectura del RDTSC no es confiable en los sistemas SMP, ya que cada CPU mantiene su propio contador y no se garantiza que cada contador esté sincronizado con respecto a otra CPU.

Podría sugerir que lo intentes clock_gettime(CLOCK_REALTIME). El manual posix indica que esto debe implementarse en todos los sistemas compatibles. Puede proporcionar un recuento de nanosegundos, pero probablemente querrá verificar clock_getres(CLOCK_REALTIME)su sistema para ver cuál es la resolución real.