¿System.nanoTime () es completamente inútil?

Como se documenta en la publicación del blog Cuidado con System.nanoTime () en Java , en sistemas x86, Java System.nanoTime () devuelve el valor de tiempo usando un contador específico de la CPU . Ahora considere el siguiente caso que uso para medir el tiempo de una llamada:

long time1= System.nanoTime();
foo();
long time2 = System.nanoTime();
long timeSpent = time2-time1;

Ahora, en un sistema multinúcleo, podría ser que después de medir el tiempo1, el subproceso esté programado para un procesador diferente cuyo contador sea menor que el de la CPU anterior. Por lo tanto, podríamos obtener un valor en time2 que sea menor que time1. Por lo tanto, obtendríamos un valor negativo en timeSpent.

Considerando este caso, ¿no es que System.nanotime es bastante inútil por ahora?

Sé que cambiar la hora del sistema no afecta el nanotime. Ese no es el problema que describo anteriormente. El problema es que cada CPU mantendrá un contador diferente desde que se encendió. Este contador puede ser inferior en la segunda CPU en comparación con la primera CPU. Dado que el sistema operativo puede programar el subproceso en la segunda CPU después de obtener time1, el valor de timeSpent puede ser incorrecto e incluso negativo.

Esta respuesta fue escrita en 2011 desde el punto de vista de lo que realmente hizo el Sun JDK de la época en los sistemas operativos de la época. ¡Eso fue hace mucho tiempo! respuesta de leventov ofrece una perspectiva más actualizada.

Esa publicación está equivocada y nanoTimees segura. Hay un comentario en la publicación que enlaza con una publicación de blog de David Holmes , un tipo en tiempo real y de concurrencia en Sun. Dice:

System.nanoTime () se implementa utilizando la API QueryPerformanceCounter / QueryPerformanceFrequency [...] El mecanismo predeterminado utilizado por QPC está determinado por la capa de abstracción de hardware (HAL) [...] Este valor predeterminado cambia no solo en el hardware sino también en el sistema operativo versiones. Por ejemplo, Windows XP Service Pack 2 cambió las cosas para usar el temporizador de administración de energía (PMTimer) en lugar del contador de marca de tiempo del procesador (TSC) debido a problemas con el TSC que no se sincroniza en diferentes procesadores en sistemas SMP, y debido al hecho de su frecuencia puede variar (y, por lo tanto, su relación con el tiempo transcurrido) según la configuración de administración de energía.

Entonces, en Windows, esto era un problema hasta WinXP SP2, pero no lo es ahora.

No puedo encontrar una parte II (o más) que habla sobre otras plataformas, pero ese artículo incluye una observación de que Linux ha encontrado y resuelto el mismo problema de la misma manera, con un enlace a las Preguntas frecuentes para clock_gettime (CLOCK_REALTIME) , que dice:

1. ¿Clock_gettime (CLOCK_REALTIME) es coherente en todos los procesadores / núcleos? (¿Importa el arco? Ej. Ppc, arm, x86, amd64, sparc).

se debe o no lo considera buggy.

Sin embargo, en x86 / x86_64, es posible ver que los TSC de frecuencia variable o no sincronizados causan inconsistencias de tiempo. Los núcleos 2.4 realmente no tenían protección contra esto, y los núcleos 2.6 tempranos tampoco funcionaron muy bien aquí. A partir de 2.6.18 en adelante, la lógica para detectar esto es mejor y generalmente recurriremos a una fuente de reloj segura.

ppc siempre tiene una base de tiempo sincronizada, por lo que no debería ser un problema.

Entonces, si se puede leer que el enlace de Holmes implica nanoTimellamadas clock_gettime(CLOCK_REALTIME), entonces es seguro desde el kernel 2.6.18 en x86, y siempre en PowerPC (porque IBM y Motorola, a diferencia de Intel, realmente saben cómo diseñar microprocesadores).

No hay mención de SPARC o Solaris, lamentablemente. Y, por supuesto, no tenemos idea de lo que hacen las JVM de IBM. Pero las JVM de Sun en Windows y Linux modernos hacen esto bien.

EDITAR: esta respuesta se basa en las fuentes que cita. Pero todavía me preocupa que pueda estar completamente equivocado. Una información más actualizada sería realmente valiosa. Acabo de encontrar un enlace a un artículo nuevo de cuatro años sobre los relojes de Linux que podría ser útil.

Hice un poco de búsqueda y descubrí que si uno es pedante, sí, podría considerarse inútil ... en situaciones particulares ... depende de cuán sensibles sean sus requisitos ...

Consulte esta cita del sitio Java Sun:

El reloj en tiempo real y System.nanoTime () se basan en la misma llamada al sistema y, por lo tanto, en el mismo reloj.

Con Java RTS, todas las API basadas en el tiempo (por ejemplo, temporizadores, subprocesos periódicos, monitoreo de fechas límite, etc.) se basan en el temporizador de alta resolución. Y, junto con las prioridades en tiempo real, pueden garantizar que el código apropiado se ejecutará en el momento adecuado para las restricciones en tiempo real. En contraste, las API Java SE comunes ofrecen solo unos pocos métodos capaces de manejar tiempos de alta resolución, sin garantía de ejecución en un momento dado. El uso de System.nanoTime () entre varios puntos en el código para realizar mediciones de tiempo transcurrido siempre debe ser preciso.

Java también tiene una advertencia para el método nanoTime () :

Este método solo se puede usar para medir el tiempo transcurrido y no está relacionado con ninguna otra noción de sistema o tiempo de reloj de pared. El valor devuelto representa nanosegundos desde un tiempo fijo pero arbitrario (quizás en el futuro, por lo que los valores pueden ser negativos). Este método proporciona precisión en nanosegundos, pero no necesariamente precisión en nanosegundos. No se garantiza con qué frecuencia cambian los valores. Las diferencias en llamadas sucesivas que abarcan más de aproximadamente 292.3 años (2 ⁶³ nanosegundos) no calcularán con precisión el tiempo transcurrido debido al desbordamiento numérico.

Parece que la única conclusión que se puede extraer es que no se puede confiar en nanoTime () como un valor preciso. Como tal, si no necesita medir tiempos que están separados por nano segundos, entonces este método es lo suficientemente bueno incluso si el valor devuelto resultante es negativo. Sin embargo, si necesita una mayor precisión, parecen recomendarle que use JAVA RTS.

Entonces, para responder a su pregunta ... no nanoTime () no es inútil ... simplemente no es el método más prudente para usar en cada situación.

No es necesario debatir, solo usa la fuente. Aquí, SE 6 para Linux, saque sus propias conclusiones:

jlong os::javaTimeMillis() {
  timeval time;
  int status = gettimeofday(&time, NULL);
  assert(status != -1, "linux error");
  return jlong(time.tv_sec) * 1000  +  jlong(time.tv_usec / 1000);
}


jlong os::javaTimeNanos() {
  if (Linux::supports_monotonic_clock()) {
    struct timespec tp;
    int status = Linux::clock_gettime(CLOCK_MONOTONIC, &tp);
    assert(status == 0, "gettime error");
    jlong result = jlong(tp.tv_sec) * (1000 * 1000 * 1000) + jlong(tp.tv_nsec);
    return result;
  } else {
    timeval time;
    int status = gettimeofday(&time, NULL);
    assert(status != -1, "linux error");
    jlong usecs = jlong(time.tv_sec) * (1000 * 1000) + jlong(time.tv_usec);
    return 1000 * usecs;
  }
}

Desde Java 7, System.nanoTime()se garantiza la seguridad de la especificación JDK. System.nanoTime()'Javadoc deja en claro que todas las invocaciones observadas dentro de una JVM (es decir, en todos los hilos) son monótonas:

El valor devuelto representa nanosegundos desde un tiempo de origen fijo pero arbitrario (quizás en el futuro, por lo que los valores pueden ser negativos). Todas las invocaciones de este método utilizan el mismo origen en una instancia de una máquina virtual Java; Es probable que otras instancias de máquinas virtuales utilicen un origen diferente.

La implementación de JVM / JDK es responsable de resolver las inconsistencias que podrían observarse cuando se llaman las utilidades subyacentes del sistema operativo (por ejemplo, las mencionadas en la respuesta de Tom Anderson ).

La mayoría de las otras respuestas antiguas a esta pregunta (escritas en 2009-2012) expresan FUD que probablemente fue relevante para Java 5 o Java 6, pero ya no es relevante para las versiones modernas de Java.

Sin embargo, vale la pena mencionar que, a pesar de nanoTime()la seguridad de las garantías de JDK , ha habido varios errores en OpenJDK que hacen que no se mantenga esta garantía en ciertas plataformas o bajo ciertas circunstancias (por ejemplo, JDK-8040140 , JDK-8184271 ). No hay errores abiertos (conocidos) en OpenJDK wrtnanoTime() en este momento, pero el descubrimiento de un nuevo error o una regresión en una versión más reciente de OpenJDK no debería sorprender a nadie.

Con eso en mente, el código que se usa nanoTime()para el bloqueo temporizado, la espera de intervalos, los tiempos de espera, etc., debe tratar preferiblemente las diferencias de tiempo negativas (tiempos de espera) como ceros en lugar de arrojar excepciones. Esta práctica también es preferible porque es coherente con el comportamiento de todos los métodos de espera cronometrados en todas las clases en java.util.concurrent.*, por ejemplo Semaphore.tryAcquire(), Lock.tryLock(),BlockingQueue.poll() , etc.

No obstante, nanoTime()aún se debe preferir para implementar el bloqueo temporizado, el intervalo de espera, los tiempos de espera, etc., currentTimeMillis()ya que este último está sujeto al fenómeno del "tiempo que retrocede" (por ejemplo, debido a la corrección de la hora del servidor), currentTimeMillis()es decir, no es adecuado para medir intervalos de tiempo en absoluto. Ver esta respuesta para más información.

En lugar de utilizar nanoTime()directamente para mediciones de tiempo de ejecución de código, se deben utilizar preferiblemente marcos de referencia y perfiladores especializados, por ejemplo JMH y async-profiler en modo de perfil de reloj de pared .

Descargo de responsabilidad: soy el desarrollador de esta biblioteca

Puede que te guste más esto:

http://juliusdavies.ca/nanotime/

Pero copia un archivo DLL o Unix .so (objeto compartido) en el directorio de inicio del usuario actual para que pueda llamar a JNI.

Alguna información de fondo está en mi sitio en:

http://juliusdavies.ca/posix_clocks/clock_realtime_linux_faq.html

Linux corrige las discrepancias entre las CPU, pero Windows no. Le sugiero que asuma que System.nanoTime () solo tiene una precisión de alrededor de 1 micro segundo. Una manera simple de obtener un tiempo más largo es llamar a foo () 1000 o más veces y dividir el tiempo entre 1000.

Absolutamente no inútil. Los aficionados al tiempo señalan correctamente el problema de múltiples núcleos, pero en aplicaciones de palabras reales a menudo es radicalmente mejor que currentTimeMillis ().

Al calcular las posiciones gráficas en las actualizaciones de cuadros, nanoTime () conduce a un movimiento MUCHO más suave en mi programa.

Y solo pruebo en máquinas multinúcleo.

He visto un tiempo transcurrido negativo informado al usar System.nanoTime (). Para ser claros, el código en cuestión es:

    long startNanos = System.nanoTime();

    Object returnValue = joinPoint.proceed();

    long elapsedNanos = System.nanoTime() - startNanos;

y la variable 'elapsedNanos' tenía un valor negativo. (Estoy seguro de que la llamada intermedia también tardó menos de 293 años, que es el punto de desbordamiento para los nanos almacenados en largos :)

Esto ocurrió utilizando un IBM v1.5 JRE de 64 bits en el hardware IBM P690 (multi-core) que ejecuta AIX. Solo he visto este error ocurrir una vez, por lo que parece extremadamente raro. No sé la causa, es un problema específico de hardware, un defecto de JVM, no lo sé. Tampoco sé las implicaciones para la precisión de nanoTime () en general.

Para responder a la pregunta original, no creo que nanoTime sea inútil: proporciona un tiempo inferior a milisegundos, pero existe un riesgo real (no solo teórico) de que sea inexacto, lo que debe tener en cuenta.

Esto no parece ser un problema en un Core 2 Duo con Windows XP y JRE 1.5.0_06.

En una prueba con tres hilos no veo que System.nanoTime () vaya hacia atrás. Los procesadores están ocupados y los hilos se van a dormir ocasionalmente para provocar hilos en movimiento.

[EDITAR] Supongo que solo ocurre en procesadores físicamente separados, es decir, que los contadores están sincronizados para múltiples núcleos en el mismo dado.

No, no lo es ... Solo depende de tu CPU, verifica el temporizador de eventos de alta precisión cómo / por qué las cosas se tratan de manera diferente según la CPU.

Básicamente, lea la fuente de su Java y verifique qué hace su versión con la función, y si funciona contra la CPU, la estará ejecutando.

IBM incluso sugiere que lo use para la evaluación comparativa del rendimiento (una publicación de 2008, pero actualizada).

Me estoy vinculando a lo que esencialmente es la misma discusión donde Peter Lawrey está proporcionando una buena respuesta. ¿Por qué obtengo un tiempo transcurrido negativo usando System.nanoTime ()?

Muchas personas mencionaron que en Java System.nanoTime () podría devolver un tiempo negativo. Pido disculpas por repetir lo que otras personas ya dijeron.

1. nanoTime () no es un reloj sino un contador de ciclos de CPU.
2. El valor de retorno se divide por la frecuencia para que parezca el tiempo.
3. La frecuencia de la CPU puede fluctuar.
4. Cuando su hilo está programado en otra CPU, existe la posibilidad de obtener nanoTime (), lo que resulta en una diferencia negativa. Eso es logico. Los contadores entre las CPU no están sincronizados.
5. En muchos casos, podría obtener resultados bastante engañosos, pero no podría saberlo porque delta no es negativo. Piénsalo.
6. (sin confirmar) Creo que puede obtener un resultado negativo incluso en la misma CPU si se reordenan las instrucciones. Para evitar eso, tendrías que invocar una barrera de memoria que serializa tus instrucciones.

Sería genial si System.nanoTime () devolviera coreID donde se ejecutó.

Java es multiplataforma y nanoTime depende de la plataforma. Si usa Java, cuando no use nanoTime. Encontré errores reales en diferentes implementaciones de jvm con esta función.

La documentación de Java 5 también recomienda usar este método para el mismo propósito.

Este método solo puede usarse para medir el tiempo transcurrido y no está relacionado con ninguna otra noción de sistema o tiempo de reloj de pared.

Java 5 API Doc

Además, System.currentTimeMillies()cambia cuando cambia el reloj de su sistema, mientras System.nanoTime()que no lo hace, por lo que este último es más seguro para medir duraciones.

nanoTimeEs extremadamente inseguro para el tiempo. Lo probé en mis algoritmos básicos de prueba de primalidad y dio respuestas que estaban literalmente separadas por un segundo para la misma entrada. No uses ese método ridículo. Necesito algo que sea más preciso y preciso que obtener tiempo millis, pero no tan malo como nanoTime.