¿Hay algún sistema de compilación que incorpore tiempos de tarea relativos esperados en el cronograma?

13

Aquí hay una pequeña ilustración de mi pregunta:

Asuma un trabajo de compilación que consta de 4 tareas independientes llamadas AD. D lleva más tiempo que AC en suma.

Un sistema de compilación que no puede incorporar los tiempos de tarea relativos podría programar las tareas de esta manera:

---------------------------------------
CPU1: A  |    C   |
---------------------------------------
CPU2: B    | D                        |
---------------------------------------

Por el contrario, si el planificador es consciente de las diferencias de tiempo de la tarea, podría llegar a este cronograma mucho más corto:

---------------------------------------
CPU1: A  |  B    |   C   |
---------------------------------------
CPU2: D                        |
---------------------------------------

Mis preguntas:

  1. ¿Hay algún sistema de compilación que incorpore tiempos de tarea relativos esperados en el cronograma?
  2. ¿Qué investigación académica sobre sistemas de construcción de este tipo existe?
  3. ¿De dónde toman estos sistemas de compilación (si existen) la información de tiempo? ¿Heurística, tiempos recopilados durante compilaciones anteriores?
  4. Si tales sistemas de compilación no existen, ¿por qué? ¿Hay algún problema que los haga menos valiosos de lo que parecen a primera vista?
scheduling research build-system sjakobi
fuente
3
La mayoría de las preguntas sobre recursos o herramientas de terceros se cierran rápidamente como "fuera de tema", pero supongo que este podría ser un caso límite que parece encajar bien con el alcance de este sitio.
Doc Brown el
1
Creo que esto se basa en la suposición errónea de que "construir" una tarea no es paralela.
Dagnelies
En la mayoría de los casos, la construcción de una tarea no es paralela, pero sí, por ejemplo, las pruebas unitarias en aplicaciones multiproceso pueden ser paralelas. En realidad, en un proyecto donde trabajo, siempre tenemos que invocar "make" con "-j1" para la ejecución de la prueba unitaria, porque de lo contrario, fallarán las pruebas unitarias multinúcleo relacionadas con el rendimiento.
juhist
@juhist En caso de que esté interesado en cambiar a un sistema de construcción más expresivo, shake tiene un concepto de recursos donde puede, por ejemplo, definir cuántos núcleos de CPU deben reservarse para sus pruebas unitarias.
sjakobi

Respuestas:

3

Microsoft Visual Studio Team System (anteriormente TFS) considera tiempos de acción de compilación y compilaciones paralelas; toma los datos del historial de compilación anterior; y aunque no creo que pueda obtener el comportamiento que desea fuera de la caja, puede personalizarlo.

Un ejemplo de algunas tareas personalizadas para trabajar en la optimización del rendimiento.

https://veegens.wordpress.com/2013/03/26/tfs-2010-build-performance-report/

Bruno Guardia
fuente
Si entiendo su respuesta y su enlace correctamente, se informan los tiempos de acción de compilación (que es una característica bastante común) pero no está claro si estos tiempos podrían usarse para mejorar el cronograma de compilación o cómo. Esto realmente no parece responder a mis preguntas originales, por lo que no otorgaré la recompensa por su respuesta.
sjakobi
No hay problema, lo que puede haberse perdido es que puede personalizar las acciones de compilación y el proceso de compilación, a través de la programación. La muestra estaba informando, pero como se indicó, el historial se toma para optimizaciones automáticas. Además, tenga en cuenta que puede configurar compilaciones paralelas. Pero luego, para asegurarse de que estén paralelos siguiendo su algoritmo, es posible que deba personalizarlo con código. Alguna referencia adicional: dotnetcurry.com/visualstudio/1177/…
Bruno Guardia
2
@BrunoGuardia: ¿puede explicar dónde en ese artículo de su enlace se menciona una opción de personalización que podría ayudar a utilizar los tiempos de tarea esperados de las acciones de compilación?
Doc Brown
0

Esto se basa en la suposición errónea de que "construir" una tarea no es paralela.

Muchos compiladores funcionan con subprocesos múltiples, por lo que una sola tarea A utilizará todas las CPU. Por lo tanto, el orden no importa. Para las tareas vinculadas de E / S, especialmente las relacionadas con redes, también comience mejor todas en paralelo desde el principio: la mayor parte del tiempo se pasará esperando una respuesta.

En otras palabras, el orden no importa ya que las tareas individuales suelen estar paralelas (como compilar, por ejemplo)

Editar:

En realidad, esta concepción de la "Tarea A en la CPU 1" también es errónea. Incluso para tareas de subproceso único, el sistema operativo que programa los procesos / subprocesos puede saltar de CPU a CPU en cada cambio de contexto. Supongo que la mayoría de los sistemas de compilación solo ejecutarán todas las tareas en paralelo y dejarán que el sistema operativo haga la programación. Las tareas más largas tomarán más tiempo y eso es todo.

Suponiendo que tiene una tarea de un solo subproceso de larga ejecución que no está vinculada a E / S , sería mucho más fácil para el sistema de compilación asignarle prioridad / importancia en lugar de intentar retrasar tareas más pequeñas para reducir los cambios de contexto del sistema operativo.

Incluso si tiene tareas tan extrañas , lo cual es bastante raro en la práctica, y tiene un sistema de construcción de programación sofisticado que funciona con heurística basada en ejecuciones anteriores (la única forma de saberlo), los beneficios que obtiene de esto pueden ser bastante pequeños. . Sin embargo, tienes un montón de complejidad adicional para mantener.

dagnelies
fuente
El paralelismo "dentro de la tarea" es un aspecto interesante y ciertamente ofrece un potencial adicional para la optimización, pero no creo que suponer que una tarea dada se escalará eficientemente a un número arbitrario de CPU es mejor que asumir que cada tarea debe ejecutarse en Un solo núcleo.
sjakobi
@sjakobi: bueno, en la práctica es bastante importante que los compiladores sean eficientes. ¿Te imaginas que esperas mucho tiempo para compilar porque solo se usa 1 de tus 16 núcleos? Eso es un no-go. Con toda la teoría, parece pasar por alto la realidad. La programación es un tema muy interesante y muy significativo. En mi humilde opinión, es relativamente inútil en el contexto de los sistemas de compilación. Una vez más, la mayoría de los compiladores de hoy en día son multiproceso de todos modos ... y si no lo son, se debería poner mucho esfuerzo en este sistema de compilación de planificación.
Dagnelies
2
Todos los compiladores de software libre ( GCC y Clang ...) para C ++ o C o Fortran o Ada son monohilos. El sistema de compilación ( make -j) puede lanzar varios procesos de compilación en paralelo.
Basile Starynkevitch
@BasileStarynkevitch: ... de hecho. Básicamente, todo el mundo lo usa -j <nb-cores>pero, lamentablemente, el valor predeterminado sigue siendo "1" ... Todavía me sorprende que nunca haya cambiado.
Dagnelies
@dagnelies: hay una gran cantidad de Makefiles que pierden algunas dependencias críticas y, por lo tanto, no funcionan (o pueden no funcionar) con -jN donde N> 1.
juhist