¿Cómo pueden ser precisos los "números de latencia de Jeff Dean que todo programador debe saber" en el contexto de diversas implementaciones de hardware?

Me refiero a este cuadro de números de latencia , atribuido a Jeff Dean en Google.

Lo que no entiendo es, ¿estos números no varían de un conjunto de hardware a otro? ¿Cómo pueden ser precisos para todos los diferentes tipos de RAM, CPU, placa base, disco duro, etc.?

Estos números (que también figuran en la programación de Norvig Teach yourself en 10 años ) son aproximados, solo útiles como (orden de) magnitud.

En realidad, el hardware actual (al menos para computadoras de escritorio o portátiles) no varía mucho, incluso entre una computadora portátil barata de 300 € y una estación de trabajo de alta gama de 10k €. La velocidad varía en un factor de aproximadamente 2 o 4 como máximo. Dicha estación de trabajo puede tener un disco más grande, más núcleos, caché y RAM. Sin embargo, esto no tiene mucho impacto en el rendimiento sin procesar de un solo subproceso.

Mire algunas cifras en http://openbenchmarking.org/ o algunos comparadores de CPU.

La llamada ley de Moore está muriendo . Mi escritorio de más de 3 años en casa (un i3770K) podría ser reemplazado (hoy, en marzo de 2016) por un i6700 que es solo un 20% más rápido.

Los números no están destinados a ser exactos. Lo que importa son las relaciones entre los órdenes de magnitud entre niveles .

Sin embargo, cuando aparece una tecnología disruptiva (por ejemplo, computación en la nube, 10GB / 100GB ethernet, nuevo módulo de kernel de red, redes de almacenamiento SSD, virtualización y contenedorización), estos números pueden ser invalidados debido a la aparición, desaparición o cambio de niveles nuevos.

Cuando se programa a un nivel muy alto, donde todo el cómputo, la creación de redes, el análisis, etc., se realizan utilizando bibliotecas no escritas por usted mismo, conocer las cifras de rendimiento de las operaciones de bajo nivel puede no ayudar mucho, ya que su oportunidad de mejorar cada una El rendimiento de la biblioteca es bastante limitado o totalmente imposible.

En su lugar, lea cuidadosamente la documentación relacionada con el rendimiento de cada biblioteca. Si una biblioteca no viene con ellos, pregúnteles, haga que sea un problema. O aprenda a comparar el software de la manera correcta.

Tener una comprensión básica de los números de latencia es importante cuando lo contrata una empresa que diseña y fabrica componentes de software. Compare eso con una compañía que diseña y fabrica automóviles y todos los componentes que contiene: el proverbial "reinventar la rueda" (goma, presión de neumáticos, huellas, etc.)

La mayoría de las compañías de software no trabajan a nivel de componentes: se pueden construir sistemas de software funcionales completos a partir de la unión de componentes. Estas compañías de software no necesitan centrarse en cómo diseñar componentes en términos de latencias; en su lugar, necesitan evaluar la calidad de los componentes que eligen.

Para resumir, (1) es muy posible que no necesite conocer los números de latencia; (2) a menos que desee ser contratado por una compañía que fabrica componentes de software (bibliotecas), ya sea para la venta o para uso interno (como en algunas de las compañías de software más grandes del mundo), (3) si necesita esos números, es su trabajo hacer los puntos de referencia usted mismo, de una manera científicamente correcta, o de lo contrario no debería estar trabajando en componentes de software.

Nadie hizo ninguna afirmación de que estos números son precisos para ningún hardware.

Sin embargo, son mucho, mucho más precisos que las suposiciones ciegas. En eso lamentablemente mucha gente basa su código.

No son perfectamente precisos, y en realidad no están destinados a serlo.

Sin embargo, son (especialmente en los números más pequeños) un poco mejores que solo el orden de magnitud. Otro punto es que puede ayudar a entender qué cosas están juntas, que las personas a veces malinterpretan que están mucho más separadas de lo que realmente están. Para un ejemplo obvio, muchas personas suponen que la predicción errónea de la rama es con frecuencia algo importante. Se puede ser un gran problema si se repite mucho, pero no es necesariamente la pena sacrificar una cantidad enorme en cualquier lugar y en cualquier otro lugar simplemente para obtener una mejor predicción de saltos (por ejemplo, si se lee de la memoria principal, o incluso caché L2 para mejorar la predicción de saltos, probablemente sea una pérdida neta).

Al mismo tiempo, sí, los órdenes de magnitud pueden ser las partes más útiles. Por ejemplo, toma alrededor de 100 veces más tiempo acceder a los datos desde la memoria principal que desde un registro. Sí, en una máquina podría ser alrededor de 97 veces más larga, y en otra podría estar más cerca de 127 veces más. Sin embargo, es casi seguro que estará más cerca de 100 que de 10 o 1000.

Personalmente, tendería a pensar que la mayoría de estos son similares a las islas en, por ejemplo, el Océano Pacífico. Las velocidades del disco duro (por ejemplo) podrían ser las islas hawaianas. Las velocidades SSD son las islas filipinas. Esto muestra el mapa a una escala lo suficientemente pequeña como para que cada uno de ellos se vea como un solo punto. Si nos acercamos, eso claramente no es cierto, pero la distancia entre las dos cadenas es muchas veces mayor que las distancias entre las islas en cualquiera de las cadenas.

Por supuesto, los números no pueden ser precisos para todas las máquinas. Y supongo que nunca se suponía que lo hicieran. Sin embargo, muestran diferencias en el orden de magnitud entre varios tipos de operaciones.

Puede encontrar algunos enlaces y datos más útiles en los comentarios de sus datos vinculados.