¿Está realmente roto el cronómetro?

Question

En la página de MSDN para Stopwatch class descubrí enlace a interesting article que hace que la siguiente declaración acerca del cronómetro:

Sin embargo, hay algunos problemas graves:

• esto puede ser poco fiable en un PC con múltiples procesadores. Debido a un error en
  , el BIOS, Start() y Stop() se deben ejecutar en el mismo procesador para obtener como resultado correcto.

• Esto no es confiable en procesadores que no tienen un reloj constante velocidad (la mayoría de los procesadores pueden reducir la velocidad del reloj para conservar energía ). Esto se explica en detalle en here.

Estoy algo confundido. He visto tons of examples de usar Cronómetro y nadie menciona estos inconvenientes. ¿Qué tan serio es esto? ¿Debo evitar el uso de Cronómetro?

Answer 1

No es roto solo tiene limitaciones. Para la mayoría de los propósitos (léase: micro-benchmarking informal) StopWatch está bien usarlo simplemente porque es lo suficientemente bueno para pruebas informales. Para fines más formales, lo más probable es que desees rodar tu propio código de instrumentación como lo harías mucho más invertido para obtener los resultados adecuados.

Answer 2

preguntas más interesantes son:

1. bajo qué condiciones se detendrá() se ejecutará en un procesador diferente de Inicio()?
   .
   En la mayoría de los escenarios de aplicación, la respuesta es "ninguno".

2. ¿bajo qué condiciones cambiará la velocidad de reloj de un procesador durante un intervalo medido?
   .
   En puntos de referencia intensivos en CPU, "ninguno".

Answer 3

Ver las notas en el artículo de MSDN:

En un equipo multiprocesador, no importa qué procesador se ejecuta en el hilo. Sin embargo, debido a errores en el BIOS o la capa de abstracción de hardware (HAL), puede obtener diferentes resultados de tiempo en diferentes procesadores. Para especificar la afinidad del procesador para un hilo, use el método ProcessThread.ProcessorAffinity.