Los mayores cuellos de botella al compilar Android desde el código fuente

¿Tienes curiosidad por saber qué cuellos de botella genera el proyecto AOSP? Dan comparte sus hallazgos, lo que podría sorprender a los lectores en cuanto a qué causa y qué no causa un cuello de botella.

Actualización 19/4 12 p.m. CT: Los tiempos de compilación aclarados son tiempos de compilación de ccache.Actualización 20/04 9:17 am CT: Lo más seguro es que la compilación 3 no fuera RAID 1. Se corrigió ese error.

En 2012 comencé a crear kernels y confié en mi confiable Core 2 Quad Q9550 para hacerlo. Si eso no fuera digno de vergüenza, entonces el hecho de que lo hice en una máquina virtual dentro de Windows probablemente garantizará eso para la mayoría de las personas que construyen Android desde la fuente.

Un entorno Ubuntu virtualizado no funciona tan bien como un entorno nativo y, oh, qué doloroso se hizo evidente cuando un kernel tardó más de 2 horas en construirse. Como quería empezar a construir Android desde el código fuente el año siguiente, sabía que mi hardware actual no funcionaría. cortarlo, y así comenzó un largo y continuo viaje para encontrar una manera de reducir esa acumulación cada vez mayor. tiempo.

En los años transcurridos desde entonces, he tenido la suerte de poder realizar pruebas en múltiples factores de forma y plataformas. Esto es importante ya que las configuraciones de compilación no son una situación única para todos con Android. Es posible que un desarrollador de aplicaciones no necesite la misma configuración que un desarrollador de juegos. Y es posible que alguien que cree solo kernels no necesite gastar tanto como alguien que necesita crear una ROM de Android completa desde el código fuente en un período de tiempo muy corto. ¿Y qué pasa con la selección del sistema operativo? ¿Qué se puede (y no se puede) usar en este momento? Espero explorar esto más también, especialmente con Windows y Canonical trabajan para llevar un Bash completo a Windows 10.

Para comenzar bien esta serie, tenemos que encontrar dónde están los mayores obstáculos potenciales en la construcción de proyectos AOSP desde el origen. No solemos ir a comprar una PC o actualizaciones sin saber dónde invertir nuestro dinero. Entonces, basándome en 3 años de investigación y resultados cuantificables, estoy listo para compartir lo que encontré. Ahora el descargo de responsabilidad esperado: estos hallazgos se basan en experiencias personales y no es posible tener en cuenta todas las combinaciones. Aquellos de ustedes que tengan su propia configuración de compilación, ¡cuéntennos y háganos saber cómo les está yendo a sus compilaciones! Los tiempos también se refieren a compilaciones con ccache habilitado y completo; generalmente era el doble cuando el ccache aún no estaba completo.

E/S de disco: Tengo que felicitar a Tom Marshall de Cyanogen, también un miembro del equipo kang - por señalarme en esta dirección el año pasado. Honestamente no le creí cuando me dijo que esto sería el cuello de botella sobre la CPU. Pero durante los últimos 6 meses he podido respaldar esto con datos cuantificables. En las CPU de gama alta (como la mayoría de los modelos Intel Core i7 de escritorio), este es el principal cuello de botella que experimentará su sistema.

Tomemos 4 configuraciones de compilación en las que he probado esto. Destacaré aquí la CPU,

  • La compilación 1, mi PC "no actualizada", era una Intel i7-4790K con 32 GB de RAM DDR3-2400, una Samsung 840 Evo de 250 GB para mi disco principal y una Micron P400E de 100 GB más antigua.
  • Build 2, que era la versión mejorada de Build 1. Ahora tiene un Intel i7-5960X overclockeado a 4,0 GHz, 32 GB de RAM DDR4-3200, un SSD Samsung SM951 de 512 GB AHCI m.2 junto con los dos SSD anteriores. Las especificaciones de compilación completas para esto están en PCPartPicker.
  • La compilación 3, una compilación de usuario reciente, presentaba un Intel i7-5820K overclockeado a 4,2 GHz, 16 GB de DDR4-2400 y 2 Samsung 840 EVO de 120 GB en configuración RAID0 (seccionada).
  • Build 4, una compilación de servidor reciente que incluye un Intel Xeon E3-1270 v5 a velocidades normales, 32 GB DDR4-2133, un Samsung 950 Pro 512 GB NVMe m.2 junto con 4 SSD empresariales SATA Samsung en una matriz RAID5.

Si solo los miraras, ¿cuál creerías que logró el menor tiempo de construcción? ¿Qué tal el segundo? Para mi sorpresa, no fue la segunda configuración la que tomó el menor tiempo de construcción, sino la tercera configuración, al menos. poco menos de 14 minutos para construir CyanogenMod 13.0. Así que, sin duda, la CPU dominante ocuparía el segundo lugar. ¿bien? Nuevamente incorrecto. ¡La compilación 4, que acabo de terminar de probar, tomó poco más de 25 minutos! Solo aquí es donde se encuentra mi versión actual, 2 minutos más lenta que un sistema con la mitad de núcleos y subprocesos pero una matriz SSD de 3 SSD, mientras que mis SSD eran independientes. También se sabe que el SM951 tiene problemas de aceleración si se calienta demasiado, algo que podría ser un factor muy real en este caso. La primera y más lenta compilación tomó alrededor de 30 minutos, una de las únicas veces que construí CM 13.0; He oído hablar de configuraciones de compilación similares que lo hacen en 27.

Los SSD también solían ser un artículo difícil de conseguir, por lo que hubo muy poca discusión sobre el tema. Sin embargo, los precios han caído drásticamente durante el último año tanto en el mercado minorista como en el de segunda mano. Con SSD de 120 GB ahora por menos de $ 50, agregar uno a un sistema ya no es la barrera que alguna vez fue. Los discos duros tradicionales también harán el trabajo, pero es más probable que los usuarios lleguen a este cuello de botella antes que los demás si no utilizan SSD.

suspensión de la CPUUPC: Cuando menciono anteriormente que el principal cuello de botella es la E/S de disco, se supone que puede no ser siempre así: cada una de las compilaciones que utilicé presentaba un Intel Core i7. Pero como descubrí con el servidor Xeon, el disco mantiene el ritmo pero luego mantiene los 8 subprocesos de la CPU en alta utilización durante los procesos de compilación más pesados. Y por más que lo intenté, sin la matriz RAID que encontramos arriba, no encuentro que mi Haswell-E esté siquiera cerca de utilizarse por completo durante la mayor parte del proceso de construcción. Entonces, si está buscando el mejor valor por su inversión en construcción, considere el Intel i7-5820K.

Es cierto que es X99, por lo que la placa base puede ser más cara que una placa base Z97; pero también estamos todavía en el primer año del ciclo X99. También se espera que los precios de Broadwell-E sigan siendo similares a los de Haswell-E en el momento del lanzamiento, lo que significa que Debería poder comprarlo en el segmento de entusiastas por casi el mismo precio que un i7-4790K o i7-6700K.

En Intel no hay muchas razones para ir más allá de un 5820K en este momento, ya que con él se pueden obtener tiempos de construcción impresionantes. En su mayor parte, cuanto mayor sea el número de núcleos/hilos a continuación, junto con las velocidades del procesador, obtendrá un tiempo de construcción más rápido. Un i7-4770R en un GIGABYTE Brix el año pasado me llevó un promedio de 42 minutos de construcción. Si bien no fue el más rápido, se adaptó a mis necesidades y me permitió tener una configuración dedicada de bajo consumo. Encontrará lo mismo con las APU de AMD: si bien es posible que actualmente no funcionen tan bien como sus contrapartes de Intel, harán el trabajo fácilmente y, por lo general, a un precio más bajo que comprar Intel. Esta es una situación que sigo de cerca porque si los rumores son ciertos, las APU basadas en Zen pueden cerrar esa brecha significativamente.

Hay un resultado para aquellos de ustedes que optarían por eliminar esos cuellos de botella, uno que se aplica más a los usuarios domésticos que a los de oficina. El rendimiento general aumentará en un sistema al eliminar estos cuellos de botella. Los jugadores en particular encontrarán que la actualización para abordar estos cuellos de botella en casi todos los casos también aumentará el rendimiento del juego. Si bien es posible que no haya obtenido el tiempo de compilación más rápido, esa segunda compilación dio una sorpresa inesperada: un tiempo de carga de 30 segundos en Causa justa 3 cuando muchos otros se quejaban de los tiempos de carga en minutos. Al final, estos tiempos de construcción son realmente altos y pueden ser excesivos para muchos... pero al menos ahora el argumento de que más núcleos significarán compilaciones más rápidas finalmente ha quedado descartado.

Dado que esto es sólo el comienzo, esperamos que los lectores intervengan y compartan sus experiencias de construcción en varias configuraciones. Como lector, ¿quieres ver más discusiones sobre este tipo de temas? ¡Apague el sonido abajo en los comentarios!