rapido - ¿Cómo hago que Windows vaya tan rápido como Linux para compilar C++?

como optimizar windows 10 al maximo (13)

Sé que esto no es tanto una pregunta de programación sino que es relevante.

Trabajo en un proyecto de plataforma cruzada bastante grande . En Windows utilizo VC ++ 2008. En Linux uso gcc. Hay alrededor de 40k archivos en el proyecto. Windows es de 10 a 40 veces más lento que Linux al compilar y vincular el mismo proyecto. ¿Cómo puedo arreglar eso?

Un solo cambio incremental construye 20 segundos en Linux y> 3 minutos en Windows. ¿Por qué? Incluso puedo instalar el enlazador ''oro'' en Linux y bajar ese tiempo a 7 segundos.

Del mismo modo, git es 10x a 40x más rápido en Linux que Windows.

En el caso de git, es posible que git no esté usando Windows de la manera óptima, ¿pero VC ++? Uno pensaría que Microsoft quisiera hacer que sus propios desarrolladores sean lo más productivos posible y una compilación más rápida contribuiría mucho a eso. Tal vez están tratando de alentar a los desarrolladores a C #?

Como prueba simple, encuentre una carpeta con muchas subcarpetas y haga una simple

dir /s > c:/list.txt

en Windows. Hazlo dos veces y mide el tiempo de la segunda ejecución para que se ejecute desde la memoria caché. Copia los archivos a Linux y haz 2 ejecuciones equivalentes y mide el tiempo de la segunda ejecución.

ls -R > /tmp/list.txt

Tengo 2 estaciones de trabajo con las mismas especificaciones exactas. HP Z600 con 12 gig de ram, 8 núcleos a 3.0 ghz. En una carpeta con ~ 400k archivos, Windows tarda 40 segundos, Linux tarda <1 segundo.

¿Existe una configuración de registro que pueda configurar para acelerar Windows? ¿Lo que da?

Algunos enlaces poco relevantes, relevantes para los tiempos de compilación, no necesariamente de E / S.

Aparentemente hay un problema en Windows 10 (no en Windows 7) que al cerrar un proceso tiene un bloqueo global . Al compilar con múltiples núcleos y, por lo tanto, múltiples procesos, este problema afecta.
La opción /analyse puede afectar negativamente a perf porque carga un navegador web . (No es relevante aquí, pero es bueno saberlo)

Enlaces incrementales

Si la solución de VC 2008 está configurada como proyectos múltiples con salidas .lib, debe establecer "Usar entradas de dependencia de biblioteca"; esto hace que el enlace del enlazador directamente contra los archivos .obj en lugar de .lib. (Y en realidad lo hace un enlace incremental).

Rendimiento transversal del directorio

Es un poco injusto comparar el rastreo de directorios en la máquina original con el rastreo de un directorio recién creado con los mismos archivos en otra máquina. Si desea una prueba equivalente, probablemente deba hacer otra copia del directorio en la máquina fuente. (Todavía puede ser lento, pero eso podría deberse a varias cosas: fragmentación del disco, nombres cortos de archivos, servicios en segundo plano, etc.) Aunque creo que los problemas de rendimiento para dir /s tienen más que ver con escribir el resultado que medir el rendimiento real del recorrido de archivos. Incluso dir /s /b > nul es lento en mi máquina con un gran directorio.

¿Cómo construyes tu gran proyecto de plataforma cruzada? Si está utilizando makefiles comunes para Linux y Windows, podría degradar fácilmente el rendimiento de Windows por un factor de 10 si los archivos make no están diseñados para ser rápidos en Windows.

Acabo de arreglar algunos makefiles de un proyecto multiplataforma usando makefiles comunes (GNU) para Linux y Windows. ¡Make está comenzando un proceso sh.exe para cada línea de una receta que causa la diferencia de rendimiento entre Windows y Linux!

De acuerdo con la documentación de GNU make

.ONEHELL:

debería resolver el problema, pero esta función (actualmente) no es compatible con Windows make. Por lo tanto, volver a escribir las recetas para que estén en líneas lógicas únicas (por ejemplo, agregando; / o / al final de las líneas actuales del editor) funcionó muy bien.

A menos que aparezca un hacker de sistemas de Windows hardcore, no obtendrás más comentarios partidistas (que no haré) y especulaciones (que es lo que voy a intentar).

Sistema de archivos: debe probar las mismas operaciones (incluido el dir ) en el mismo sistema de archivos. Me encontré con this que compara algunos sistemas de archivos para varios parámetros.
Almacenamiento en caché Una vez intenté ejecutar una compilación en Linux en un disco RAM y descubrí que era más lento que ejecutarlo en el disco gracias a la forma en que el kernel se ocupa del almacenamiento en caché. Este es un sólido punto de venta para Linux y podría ser la razón por la cual el rendimiento es tan diferente.
Las malas especificaciones de dependencia en Windows. Quizás las especificaciones de dependencia de cromo para Windows no sean tan correctas como para Linux. Esto podría dar lugar a compilaciones innecesarias cuando realiza un pequeño cambio. Es posible que pueda validar esto utilizando la misma cadena de herramientas del compilador en Windows.

Algunas ideas:

Deshabilita 8.3 nombres. Esto puede ser un factor importante en unidades con una gran cantidad de archivos y un número relativamente pequeño de carpetas: fsutil behavior set disable8dot3 1
Usa más carpetas. En mi experiencia, NTFS comienza a desacelerarse con más de 1000 archivos por carpeta.
Habilitar compilaciones paralelas con MSBuild; simplemente agregue el interruptor "/ m" y automáticamente comenzará una copia de MSBuild por núcleo de CPU.
Coloque sus archivos en una SSD: ayuda enormemente en E / S aleatorias.
Si el tamaño promedio de su archivo es mucho mayor que 4KB, considere reconstruir el sistema de archivos con un tamaño de clúster mayor que corresponda aproximadamente al tamaño promedio de su archivo.
Asegúrese de que los archivos hayan sido desfragmentados. Los archivos fragmentados provocan muchas búsquedas en el disco, lo que puede costarle un factor de 40+ en el rendimiento. Utilice la utilidad "contig" de sysinternals o el desfragmentador de Windows incorporado.
Si su tamaño de archivo promedio es pequeño y la partición en la que se encuentra está relativamente llena, es posible que esté ejecutando una MFT fragmentada, lo cual es malo para el rendimiento. Además, los archivos de menos de 1 KB se almacenan directamente en el MFT. La utilidad "contig" mencionada anteriormente puede ayudar, o puede necesitar aumentar el tamaño de MFT. El siguiente comando lo duplicará, hasta el 25% del volumen: fsutil behavior set mftzone 2 Cambie el último número a 3 o 4 para aumentar el tamaño en incrementos adicionales de 12.5%. Después de ejecutar el comando, reinicie y luego cree el sistema de archivos.
Deshabilitar el último tiempo de acceso: fsutil behavior set disablelastaccess 1
Deshabilitar el servicio de indexación
Deshabilite su software antivirus y antispyware, o al menos configure las carpetas relevantes para ignorarlas.
Coloque sus archivos en una unidad física diferente desde el SO y el archivo de paginación. El uso de una unidad física separada permite a Windows usar E / S paralelas en ambas unidades.
Eche un vistazo a las banderas de su compilador. El compilador de Windows C ++ tiene un montón de opciones; asegúrese de usar solo los que realmente necesita.
Intente aumentar la cantidad de memoria que el sistema operativo usa para los búferes de grupo paginado (asegúrese de tener suficiente memoria RAM primero): fsutil behavior set memoryusage 2
Verifique el registro de errores de Windows para asegurarse de que no tenga errores ocasionales en el disco.
Eche un vistazo a los contadores de rendimiento relacionados con el Disco físico para ver qué tan ocupados están sus discos. Las altas longitudes de cola o los largos tiempos por transferencia son malos signos.
El primer 30% de las particiones del disco es mucho más rápido que el resto del disco en términos de tiempo de transferencia en bruto. Las particiones más angostas también ayudan a minimizar los tiempos de búsqueda.
¿Estás usando RAID? Si es así, es posible que necesite optimizar su elección del tipo de RAID (RAID-5 es malo para operaciones de escritura pesada como la compilación)
Deshabilita cualquier servicio que no necesites
Desfragmentar carpetas: copie todos los archivos en otra unidad (solo los archivos), elimine los archivos originales, copie todas las carpetas en otra unidad (solo las carpetas vacías), elimine las carpetas originales, defragmente la unidad original, copie la estructura de carpetas primero , luego copia los archivos. Cuando Windows crea grandes carpetas un archivo a la vez, las carpetas terminan siendo fragmentadas y lentas. ("contig" también debería ayudar aquí)
Si está vinculado a E / S y tiene ciclos de CPU de sobra, intente activar la compresión del disco. Puede proporcionar algunas aceleraciones significativas para archivos altamente comprimibles (como el código fuente), con algún costo en la CPU.

El problema con Visual C ++ es, hasta donde puedo decir, que no es una prioridad para el equipo del compilador optimizar este escenario. Su solución es que use su característica de encabezado precompilado. Esto es lo que han hecho los proyectos específicos de Windows. No es portátil, pero funciona.

Además, en Windows normalmente tiene escáneres de virus, así como herramientas de restauración y búsqueda del sistema que pueden arruinar completamente sus tiempos de compilación si supervisan su carpeta de compilación por usted. El monitor de recursos de Windows 7 puede ayudarlo a detectarlo. Tengo una respuesta aquí con algunos consejos adicionales para optimizar los tiempos de compilación de vc ++ si realmente está interesado.

En mi humilde opinión, esto se trata de rendimiento de E / S de disco. El orden de magnitud sugiere que muchas de las operaciones se transfieren a un disco bajo Windows mientras que se manejan en memoria bajo Linux, es decir, Linux almacena en caché mejor. Su mejor opción en Windows será mover sus archivos a un disco rápido, servidor o sistema de archivos. Considere comprar una unidad de estado sólido o mover sus archivos a un disco RAM o servidor NFS rápido.

Ejecuté las pruebas de recorrido del directorio y los resultados están muy cerca de los tiempos de compilación informados, lo que sugiere que esto no tiene nada que ver con los tiempos de procesamiento de la CPU o los algoritmos del compilador / enlazador.

Tiempos medidos como se sugiere arriba atravesando el árbol de directorio de cromo:

Windows Home Premium 7 (8GB Ram) en NTFS: 32 segundos
Ubuntu 11.04 Linux (2GB Ram) en NTFS: 10 segundos
Ubuntu 11.04 Linux (2GB Ram) en ext4: 0.6 segundos

Para las pruebas extraje las fuentes de cromo (ambas en win / linux)

git clone http://github.com/chromium/chromium.git cd chromium git checkout remotes/origin/trunk

Para medir el tiempo que corrí

ls -lR > ../list.txt ; time ls -lR > ../list.txt # bash dir -Recurse > ../list.txt ; (measure-command { dir -Recurse > ../list.txt }).TotalSeconds #Powershell

Desactivé las marcas de tiempo de acceso, mi antivirus y aumenté la configuración del administrador de caché en Windows (> 2 GB de RAM), todo sin mejoras notables. La realidad es que Linux ejecutó 50 veces mejor que Windows con una cuarta parte de la memoria RAM.

Para cualquiera que quiera afirmar que los números son incorrectos, por cualquier razón, pruébelo y publique sus hallazgos.

Estoy bastante seguro de que está relacionado con el sistema de archivos. Trabajo en un proyecto multiplataforma para Linux y Windows donde todo el código es común, excepto cuando el código dependiente de la plataforma es absolutamente necesario. Usamos Mercurial, no git, por lo que la "Linuxness" de git no se aplica. Llevar los cambios desde el repositorio central toma para siempre en Windows en comparación con Linux, pero tengo que decir que nuestras máquinas con Windows 7 son mucho mejores que las de Windows XP. Compilar el código después de eso es aún peor en VS 2008. No es solo hg; CMake también funciona mucho más despacio en Windows, y ambas herramientas usan el sistema de archivos más que cualquier otra cosa.

El problema es tan grave que la mayoría de nuestros desarrolladores que trabajan en un entorno Windows ni siquiera se molestan en hacer compilaciones incrementales, sino que se dan cuenta de que hacer una compilación unitaria es más rápido.

Por cierto, si quieres aumentar drásticamente la velocidad de compilación en Windows, te sugiero la compilación unitaria antes mencionada. Es un dolor implementarlo correctamente en el sistema de compilación (lo hice para nuestro equipo en CMake), pero una vez hecho automaticamente, acelera las cosas para nuestros servidores de integración continua. Dependiendo de cuántos binarios esté escupiendo su sistema de compilación, puede obtener de 1 a 2 órdenes de mejora de magnitud. Su experiencia puede ser diferente. En nuestro caso, creo que aceleró las compilaciones de Linux en tres partes y las de Windows en aproximadamente un factor de 10, pero tenemos muchas bibliotecas y ejecutables compartidos (lo que disminuye las ventajas de una compilación unificada).

La dificultad para hacerlo se debe al hecho de que C ++ tiende a propagarse y al proceso de compilación en muchos archivos pequeños e individuales. Eso es algo en lo que Linux es bueno y Windows no. Si desea crear un compilador de C ++ realmente rápido para Windows, intente mantener todo en la memoria RAM y toque el sistema de archivos lo menos posible.

Así es también como crearás una cadena de compilación de Linux C ++ más rápida, pero es menos importante en Linux porque el sistema de archivos ya está haciendo una gran cantidad de ajustes para ti.

La razón de esto se debe a la cultura de Unix: Históricamente, el rendimiento del sistema de archivos ha sido una prioridad mucho más alta en el mundo de Unix que en Windows. No quiere decir que no haya sido una prioridad en Windows, solo que en Unix ha sido una prioridad más alta.

Acceso al código fuente
No puedes cambiar lo que no puedes controlar. La falta de acceso al código fuente de Windows NTFS significa que la mayoría de los esfuerzos para mejorar el rendimiento se han logrado a través de mejoras de hardware. Es decir, si el rendimiento es lento, se soluciona el problema mejorando el hardware: el bus, el medio de almacenamiento, etc. Solo puede hacer mucho si tiene que solucionar el problema, no solucionarlo.
El acceso al código fuente de Unix (incluso antes del código abierto) estaba más extendido. Por lo tanto, si desea mejorar el rendimiento, debe abordarlo primero en el software (más barato y más fácil) y el hardware en segundo lugar.
Como resultado, hay muchas personas en el mundo que obtuvieron sus doctorados al estudiar el sistema de archivos Unix y encontrar nuevas formas de mejorar el rendimiento.
Unix tiende hacia muchos archivos pequeños; Windows tiende a unos pocos (o un solo) archivo grande.
Las aplicaciones de Unix tienden a tratar con muchos archivos pequeños. Piense en un entorno de desarrollo de software: muchos archivos fuente pequeños, cada uno con su propio propósito. La etapa final (vinculación) crea un archivo grande pero es un porcentaje pequeño.
Como resultado, Unix tiene llamadas al sistema altamente optimizadas para abrir y cerrar archivos, escanear directorios, etc. La historia de los artículos de investigación de Unix abarca décadas de optimizaciones de sistemas de archivos que se centran en mejorar el acceso a directorios (búsquedas y escaneos de directorios completos), la apertura inicial de archivos, etc.
Las aplicaciones de Windows tienden a abrir un archivo grande, mantenerlo abierto durante mucho tiempo y cerrarlo cuando termine. Piensa en MS-Word. msword.exe (o lo que sea) abre el archivo una vez y lo agrega durante horas, actualiza los bloques internos, etc. El valor de optimizar la apertura del archivo sería una pérdida de tiempo.
La historia de la evaluación comparativa y la optimización de Windows ha estado en la velocidad con la que uno puede leer o escribir archivos largos. Eso es lo que se optimiza.
Lamentablemente, el desarrollo de software ha tendido a la primera situación. Diablos, el mejor sistema de procesamiento de textos para Unix (TeX / LaTeX) lo alienta a poner cada capítulo en un archivo diferente y #incluirlos todos juntos.
Unix se centra en el alto rendimiento; Windows se centra en la experiencia del usuario
Unix comenzó en la sala de servidores: sin interfaz de usuario. Lo único que ven los usuarios es la velocidad. Por lo tanto, la velocidad es una prioridad.
Windows comenzó en el escritorio: a los usuarios solo les importa lo que ven y ven la IU. Por lo tanto, se gasta más energía en mejorar la UI que en el rendimiento.
El ecosistema de Windows depende de la obsolescencia planificada. ¿Por qué optimizar el software cuando el nuevo hardware está a solo un año o dos de distancia?
No creo en las teorías de la conspiración, pero si lo hiciera, señalaría que en la cultura de Windows hay menos incentivos para mejorar el rendimiento. Los modelos comerciales de Windows dependen de que las personas compren máquinas nuevas como un mecanismo de relojería. (Es por eso que el precio de las acciones de miles de compañías se ve afectado si MS despacha un sistema operativo con retraso o si Intel falla una fecha de lanzamiento de un chip). Esto significa que hay un incentivo para resolver problemas de rendimiento al decirle a las personas que compren hardware nuevo; no mejorando el problema real: sistemas operativos lentos. Unix proviene de la academia donde el presupuesto es ajustado y usted puede obtener su doctorado al inventar una nueva forma de hacer que los sistemas de archivos sean más rápidos; rara vez alguien en la academia obtiene puntos por resolver un problema al emitir una orden de compra. En Windows no existe una conspiración para mantener el software lento, pero todo el ecosistema depende de la obsolescencia planificada.
Además, como Unix es de código abierto (incluso cuando no lo era, todos tenían acceso a la fuente), cualquier estudiante de doctorado aburrido puede leer el código y hacerse famoso al mejorarlo. Eso no sucede en Windows (MS tiene un programa que le da acceso a los académicos al código fuente de Windows, rara vez se aprovecha). Mire esta selección de documentos de rendimiento relacionados con Unix: http://www.eecs.harvard.edu/margo/papers/ o consulte la historia de los trabajos de Osterhaus, Henry Spencer u otros. Diablos, uno de los debates más grandes (y el más divertido de ver) en la historia de Unix fue el ir y venir entre Osterhaus y Selzer http://www.eecs.harvard.edu/margo/papers/usenix95-lfs/supplement/rebuttal.html No ves ese tipo de cosas sucediendo en el mundo de Windows. Es posible que veas vendedores que se complementan entre sí, pero eso parece ser mucho más raro últimamente, ya que la innovación parece ser a nivel del cuerpo normativo.

Así es como lo veo.

Actualización: Si observas las nuevas cadenas de compiladores que salen de Microsoft, serás muy optimista porque gran parte de lo que hacen facilita mantener toda la cadena de herramientas en la memoria RAM y repetir menos trabajo. Cosas muy impresionantes

NTFS guarda el tiempo de acceso al archivo cada vez. Puedes intentar deshabilitarlo: "fsutil behavior set disablelastaccess 1" (reiniciar)

Personalmente, me pareció que ejecutar una máquina virtual de Windows en Linux logró eliminar una gran parte de la lentitud de IO en Windows, probablemente porque el linux vm estaba almacenando mucho el caché que Windows mismo no tenía.

Al hacer eso, pude acelerar los tiempos de compilación de un gran proyecto de C ++ (250Kloc) en el que trabajé desde aproximadamente 15 minutos hasta aproximadamente 6 minutos.

Quiero agregar solo una observación usando Gnu make y otras herramientas de las herramientas MinGW en Windows: Parecen resolver nombres de host incluso cuando las herramientas ni siquiera se pueden comunicar a través de IP. Supongo que esto es causado por alguna rutina de inicialización del tiempo de ejecución de MinGW. La ejecución de un proxy DNS local me ayudó a mejorar la velocidad de compilación con estas herramientas.

Antes de tener un gran dolor de cabeza porque la velocidad de construcción se redujo en un factor de 10 o más cuando abrí una conexión VPN en paralelo. En este caso, todas estas búsquedas DNS pasaron por la VPN.

Esta observación también podría aplicarse a otras herramientas de compilación, no solo basadas en MinGW, y podría haber cambiado en la última versión de MinGW mientras tanto.

Recientemente pude archivar de otra manera para acelerar la compilación en un 10% en Windows usando Gnu make al reemplazar mingw bash.exe con la versión de win-bash

Pruebe usar jom en lugar de nmake

Consíguelo aquí: http://qt.gitorious.org/qt-labs/jom

El hecho es que nmake usa solo uno de sus núcleos, jom es un clon de nmake que hace uso de procesadores multinúcleo.

GNU lo hace desde el primer momento gracias a la opción -j, que podría ser una razón de su velocidad frente al nmake de Microsoft.

jom funciona ejecutando en paralelo diferentes comandos make en diferentes procesadores / núcleos. Pruébalo y siente la diferencia!