Por qué la primera vez que se ejecuta el progtwig C, se ejecuta 10 veces más lento

Mi progtwig C que utiliza la clasificación se ejecuta 10 veces más lento la primera vez que en otras ocasiones. Utiliza el archivo de enteros para ordenar e incluso si cambio los números, el progtwig aún se ejecuta más rápido. Cuando reinicio la PC, el progtwig por primera vez se ejecuta 10 veces más lento. Aprovecho el time para contar el tiempo.

El sistema operativo almacena los datos en la RAM, aunque ya no sea necesario (esto se denomina “almacenamiento en caché”), por lo que cuando el progtwig se ejecuta de nuevo, obtiene todos los datos desde allí y no hay E / S en el disco. Incluso cuando cambia los datos, ese cambio ocurre primero en la RAM y permanece allí incluso después de que se haya escrito en el archivo.

Aunque no se queda en la memoria RAM para siempre, fíjate. Si la memoria es necesaria para otra cosa, el caché se elimina. En ese momento, se necesita un acceso al disco (y se almacena en caché en la RAM nuevamente en ese momento).

Es por esto que el primer acceso después de un reinicio siempre es lento; los datos aún no se han almacenado en caché, ya que nunca se leyeron del archivo.

Tienes que hacer hipótesis y confrontarlas a la realidad. ¡Lo primero que puedes hacer razonablemente es que huele mucho como un problema de almacenamiento en caché!

Hágase esas preguntas:

  • ¿Mis datos caben en la RAM libre (= mi caché del OS FS almacena en caché mi archivo?)
  • ¿Mis datos encajan en el caché de datos de la CPU?
  • ¿Mis datos encajan en el caché interno del disco duro?

    1. La hipótesis más fácil de descartar es la caché de FS. Bajo Linux, simplemente ejecute sync; echo 3 > /proc/sys/vm/drop_caches sync; echo 3 > /proc/sys/vm/drop_caches entre cada llamada a su progtwig. El primero se asegurará de que los datos en caché lleguen al medio físico (disco duro), el segundo eliminará el contenido del caché del sistema de archivos de la memoria.

    2. El ‘medio físico’ podría ser el propio caché del disco duro, así que tenga cuidado … Bajo Linux puede deshabilitar este caché de ” hdparm -W 0 ” con el comando hdparm -W 0 , por ejemplo, si está trabajando con la unidad sda , hdparm -W 0 /dev/sda hará el trabajo. Es posible que desee volver a habilitarlo una vez que haya terminado con sus pruebas 🙂

    3. Otra hipótesis es la memoria caché de la CPU, eche un vistazo a ¿Cómo puedo hacer una descarga de la memoria caché de la CPU en Windows x86? y cómo borrar el caché de CPU L1 y L2

Bueno, puede o no ser uno de esos, pero no duele intentarlo 🙂

Esto no es nada nuevo, no solo su progtwig, muchos softwares comerciales populares enfrentan este problema.

Para comenzar, consulte este artículo de MATLAB sobre la ejecución lenta en tiempo de puño

En el caso de otro lenguaje de progtwigción que se ejecuta en una Máquina Virtual como C # o Java, esto es bastante común. http://en.wikipedia.org/wiki/Just-in-time_comstacktion#Startup_delay_and_optimizations

El almacenamiento en caché es una buena razón para que eso suceda en C, pero aún así 10 veces es una duración bastante larga. También puede ser que su sistema esté cargando otros recursos después de reiniciar.

Debe ejecutar el progtwig después de 10 minutos después de reiniciar para obtener mejores resultados. Toda la aplicación de inicio se cargaría en ese momento. (10 minutos —- depende del número de aplicaciones de inicio y del tiempo que se tarda en iniciar cada una de ellas)

Si su progtwig tiene acceso a la red, ese podría ser el motivo del retraso inicial. Muchos protocolos de red necesitan tiempo para configurar cosas. Algunos ejemplos:

  • DNS: si su progtwig tiene acceso a la red, es probable que deba resolver un nombre de host a una dirección IP. La primera vez necesitaría al menos un viaje de ida y vuelta en red para rellenar un caché local. Las siguientes solicitudes serían más cortas.
  • Sistemas de archivos en red (NFS, CIFS y otros): los archivos pueden abrirse a través de la red.
  • Incluso algunas funciones de biblioteca aparentemente inocuas pueden requerir acceso a la red: la lista de usuarios para el host puede estar en un servidor de directorio remoto.

Aparte de esto, puede usar una herramienta de rastreo de bajo nivel para ver dónde se gasta el tiempo. En linux una herramienta básica es strace -r . Probablemente hay alguna herramienta similar para otros sistemas. Su comstackdor también debe venir con un generador de perfiles (es decir, gprof para GCC o tal vez Valgrind).

Esto se debe a la optimización del comstackdor, lo que hace es que almacena en caché el resultado de Temoparal Locality y el registro de activación se guarda, el tiempo también se guarda porque el objeto de enlace no debe volver a cargarse durante la Etapa de Enlace.

Hay dos componentes para el tiempo medido.

Si está leyendo un archivo del disco y lo está cargando en la memoria y clasificando:

1) Tiempo para leer el archivo y almacenarlo en una matriz 2) Tiempo de clasificación

¿Se midieron por separado?

¿Puedes ver esto? Invalidar el caché de búfer de Linux

En lugar de hacer un reinicio, si la repetición del experimento con el borrado de la memoria caché produce el mismo resultado, puede inferir que no se tuvieron en cuenta los efectos de almacenamiento en caché del búfer de archivos.