time - traducida - ¿Qué tan preciso es el tiempo de Go, realmente?

time go caught a ghost traducida

Question

El paquete de tiempo de Go afirma que da una precisión de nanosegundos. http://golang.org/src/pkg/time/time.go

Me pregunto cómo se implementa y si puedo confiar en él. Mis dudas vienen de Python, que claramente documenta sus dificultades y limitaciones con el tiempo:

Desde http://docs.python.org/2/library/time.html

La precisión de las diversas funciones en tiempo real puede ser menor que la sugerida por las unidades en las que se expresa su valor o argumento. Por ejemplo, en la mayoría de los sistemas Unix, el reloj "marca" solo 50 o 100 veces por segundo.

Por otro lado, la precisión de time () y sleep () es mejor que sus equivalentes de Unix: los tiempos se expresan como números flotantes, time () devuelve el tiempo más preciso disponible (usando Unix gettimeofday () donde esté disponible), y sleep () aceptará un tiempo con una fracción distinta de cero (se usa Unix select () para implementar esto, donde esté disponible).

Dado que los sistemas operativos le están dando un momento tan difícil a python, ¿cómo consigue Go su precisión de nanosegundos?

Answer 1

Uno de los problemas con la función time.time de Python es que devuelve un flotante . Un flotador es un número de doble precisión IEEE 754 que tiene 53 bits de precisión.

Dado que ahora son más de 2 ** 30 segundos desde 1970-01-01 (la época), necesita 61 (31 + 30) bits de precisión para almacenar el tiempo exacto en nanosegundos desde 1970-01-01.

Desafortunadamente eso es 7 u 8 bits menos de lo que puede almacenar en un flotador de pitón, lo que significa que los flotantes de pitón siempre serán menos precisos que el tiempo de ir.

Para cuantificar que la demostración a continuación muestra que el tiempo python es más preciso que 100nS simplemente debido a las limitaciones del tipo float .

>>> t = time()
>>> t
1359587524.591781
>>> t == t + 1E-6
False
>>> t == t + 1E-7
True

Así que vaya, comenzando con un int64 y contar en nS no tiene estas limitaciones y se limita a la precisión del SO subyacente, como lo explica muy bien nemo.

Answer 2

En cuanto a la implementación, time.Now() vuelve a una función implementada en el tiempo de ejecución. Puede revisar la implementación del tiempo C y la implementación para el time·now en el ensamblaje (linux amd64 en este caso). Esto utiliza clock_gettime , que proporciona una resolución de nano segundos. En Windows, esto se realiza llamando a GetSystemTimeAsFileTime , que también genera nanosegundos (no como alta resolución sino nanosegundos).

Entonces, sí, la resolución depende del sistema operativo y no se puede esperar que sea precisa en todos los sistemas operativos, pero los desarrolladores están tratando de hacerlo tan bueno como sea posible. Por ejemplo, en go1.0.3, time·now para FreeBSD usa gettimeofday lugar de clock_gettime , que solo ofrece una precisión de milisegundos. Puede ver esto mirando el valor almacenado en AX , ya que es la identificación syscall . Si echa un vistazo al conjunto al que se hace referencia, puede ver que el valor ms se multiplica por 1000 para obtener los nanosegundos. Sin embargo, esto está arreglado ahora .

Si quiere estar seguro, consulte las implementaciones correspondientes en el código fuente de tiempo de ejecución y consulte los manuales de su sistema operativo.