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

142

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

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

Una compilación incremental de un solo cambio 20 segundos en Linux y> 3 minutos en Windows. ¿Por qué? Incluso puedo instalar el enlazador 'gold' en Linux y reducir 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é utilizando Windows de la manera óptima sino VC ++? Uno pensaría que Microsoft querría hacer que sus propios desarrolladores fueran lo más productivos posible y una compilación más rápida contribuiría en gran medida a eso. ¿Quizás 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 cronometra la segunda ejecución para que se ejecute desde el caché. Copie los archivos a Linux y realice las 2 ejecuciones equivalentes y cronometre la segunda ejecución.

ls -R > /tmp/list.txt

Tengo 2 estaciones de trabajo con exactamente las mismas especificaciones. HP Z600s 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.

¿Hay alguna configuración de registro que pueda configurar para acelerar Windows? ¿Lo que da?


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

gman
fuente
55
No sé por qué, pero esta es una diferencia conocida en las características de rendimiento de Windows y Linux, Linux es MUCHO mejor que Windows para manejar cargas de archivos en un solo directorio, ¿posiblemente sea solo NTFS vs ext4 / lo que sea? También podría ser que el equivalente de Windows del caché dentry de Linux no sea tan bueno.
Spudd86
73
¿Por qué se cerró esto? "¿No ser constructivo"? Lo encuentro bastante relevante para los desarrolladores.
Nils
3
Esta pregunta incluye hechos y puede estar respaldada por cualquier número de hechos, referencias, cualquier cosa. El solo hecho de pensar que un título parece controvertido no debería impedir que discutamos un tema de larga data pero que no se habla lo suficiente. Siendo un usuario de Windows desde hace mucho tiempo, me gustaría hacer esta pregunta y espero obtener algunas respuestas productivas en cualquier momento. Vuelva a abrir la pregunta a menos que pueda proporcionar evidencia real de que la pregunta es inherentemente argumentativa y no está respaldada por hechos. De lo contrario, solo estás siendo un moderador.
Halil Özgür
2
@ HalilÖzgür: OK, su comentario me llevó a mirar el historial de revisiones: el título original de la pregunta era algo así. Eso puede muy bien haber sido la razón (que no voté a cerrar), porque no era un puesto por alguien claramente ofendido por el título original y comenzó a rabiar, que luego fue eliminada, lo que lleva al cierre de esta pregunta. El título ha sido editado desde entonces, así que creo que estamos listos. Reabierto. Tenga en cuenta que aún debe tratar de no discutir la pregunta ... ya que el OP está buscando respuestas, proporcionar respuestas, nada más.
BoltClock
2
Sería increíble ver a alguien como @ raymond-chen intervenir con algunas ideas, si la pregunta sigue siendo técnica y ofrece datos / hechos lo suficientemente claros como para reproducir el problema.
Benjamin Podszun

Respuestas:

32

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

  1. Sistema de archivos: debe intentar las mismas operaciones (incluida la dir) en el mismo sistema de archivos. Encontré esto que compara algunos sistemas de archivos para varios parámetros.

  2. 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 núcleo se encarga del almacenamiento en caché. Este es un punto de venta sólido para Linux y podría ser la razón por la cual el rendimiento es tan diferente.

  3. Malas especificaciones de dependencia en Windows. Tal vez las especificaciones de dependencia de cromo para Windows no son tan correctas como para Linux. Esto puede generar compilaciones innecesarias cuando realiza un pequeño cambio. Es posible que pueda validar esto utilizando la misma cadena de herramientas del compilador en Windows.

Noufal Ibrahim
fuente
¿Podrías elaborar un poco sobre el # 2? Es bastante sorprendente, ¿es porque el kernel no almacena en caché los datos del disco RAM o algo así?
user541686
2
Si asigna una parte de la memoria como un disco RAM, no está disponible para el kernel para el almacenamiento en caché o para cualquier otra cosa. En efecto, estás retorciéndole la mano y obligándola a usar menos memoria para sus propios algoritmos. Mi conocimiento es empírico. Perdí rendimiento cuando usé un disco RAM para compilaciones.
Noufal Ibrahim
1
"A menos que aparezca [un experto en un tema específico], no obtendrá más que comentarios partidistas ... y especulaciones": ¿en qué se diferencia eso de cualquier otra pregunta?
Dolph
1
Este, gracias al tema Win vs. Lin es más un imán fanboy. Además, la pregunta está bastante matizada a diferencia de las directas que solo piden comandos o métodos de uso.
Noufal Ibrahim
El enlace en el n. ° 1 ya no está activo.
alkasmo el
28

Algunas ideas

  1. Deshabilitar 8.3 nombres. Esto puede ser un factor importante en las unidades con una gran cantidad de archivos y una cantidad relativamente pequeña de carpetas:fsutil behavior set disable8dot3 1
  2. Usa más carpetas. En mi experiencia, NTFS comienza a disminuir con más de 1000 archivos por carpeta.
  3. Habilitar compilaciones paralelas con MSBuild; simplemente agregue el modificador "/ m", y automáticamente iniciará una copia de MSBuild por núcleo de CPU.
  4. Ponga sus archivos en un SSD: es de gran ayuda para E / S aleatorias.
  5. 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 más grande que corresponda aproximadamente al tamaño promedio de su archivo.
  6. Asegúrese de que los archivos hayan sido desfragmentados. Los archivos fragmentados causan muchas búsquedas de disco, lo que puede costarle un factor de más de 40 en rendimiento. Use la utilidad "contig" de sysinternals, o el desfragmentador de Windows incorporado.
  7. Si el tamaño promedio de su archivo es pequeño y la partición en la que se encuentra está relativamente llena, es posible que esté ejecutando una MFT fragmentada, lo que es malo para el rendimiento. Además, los archivos de menos de 1K se almacenan directamente en la MFT. La utilidad "contig" mencionada anteriormente puede ayudar, o puede que necesite aumentar el tamaño de MFT. El siguiente comando lo duplicará al 25% del volumen: fsutil behavior set mftzone 2cambie el último número a 3 o 4 para aumentar el tamaño en incrementos adicionales del 12.5%. Después de ejecutar el comando, reinicie y luego cree el sistema de archivos.
  8. Desactivar el último tiempo de acceso: fsutil behavior set disablelastaccess 1
  9. Deshabilitar el servicio de indexación
  10. Desactive su software antivirus y antispyware, o al menos configure las carpetas relevantes para que se ignoren.
  11. Coloque sus archivos en una unidad física diferente del sistema operativo y el archivo de paginación. El uso de una unidad física separada permite que Windows use E / S paralelas en ambas unidades.
  12. Echa un vistazo a las banderas de tu compilador. El compilador de Windows C ++ tiene muchas opciones; asegúrese de usar solo los que realmente necesita.
  13. Intente aumentar la cantidad de memoria que usa el sistema operativo para los búferes de grupo paginado (primero asegúrese de tener suficiente RAM): fsutil behavior set memoryusage 2
  14. Verifique el registro de errores de Windows para asegurarse de que no experimente errores ocasionales en el disco.
  15. Eche un vistazo a los contadores de rendimiento relacionados con el disco físico para ver qué tan ocupados están sus discos. Largas colas o largos tiempos por transferencia son malas señales.
  16. El primer 30% de las particiones de disco es mucho más rápido que el resto del disco en términos de tiempo de transferencia sin procesar. Las particiones más estrechas también ayudan a minimizar los tiempos de búsqueda.
  17. ¿Estás usando RAID? Si es así, es posible que deba optimizar su elección del tipo de RAID (RAID-5 es malo para operaciones de escritura pesada como la compilación)
  18. Desactiva cualquier servicio que no necesites
  19. Desfragmentar carpetas: copie todos los archivos a otra unidad (solo los archivos), elimine los archivos originales, copie todas las carpetas a otra unidad (solo las carpetas vacías), luego elimine las carpetas originales, desfragmente la unidad original, copie primero la estructura de carpetas , luego copie los archivos. Cuando Windows crea grandes carpetas de un archivo a la vez, las carpetas terminan fragmentadas y lentas. ("contig" también debería ayudar aquí)
  20. Si está vinculado a E / S y le sobran ciclos de CPU, 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.
RickNZ
fuente
1
Incluso si hicieras todas estas cosas, no te acercarías al rendimiento de Linux. Pruebe la prueba a continuación y publique su momento si no está de acuerdo.
b7kich
66
Necesitamos un mejor punto de referencia. No es muy útil medir el tiempo que lleva enumerar una carpeta. NTFS está optimizado para tiempos de búsqueda de un solo archivo, con una estructura btree. En Linux (la última vez que miré), una aplicación puede leer una carpeta completa con una sola llamada al sistema e iterar a través de la estructura resultante completamente en código de usuario; Windows requiere una llamada sys separada para cada archivo. De cualquier manera, los compiladores no debería necesitar para leer toda la carpeta ....
RickNZ
3
Entonces, lo que estás describiendo es precisamente el problema. Elegir un punto de referencia diferente no resuelve el problema, solo estás mirando hacia otro lado.
b7kich
2
La pregunta era sobre la optimización de los tiempos de compilación. Los tiempos de enumeración de carpetas no dominan los tiempos de compilación en Windows, incluso con decenas de miles de archivos en una carpeta.
RickNZ
1
Después de hacer algunos de los cambios sugeridos anteriormente, la segunda ejecución de "ls -R" para el árbol de cromo me lleva 4,3 segundos (frente a 40 segundos en el OP). "dir / s" tarda aproximadamente un segundo. Cambiar a un SSD no ayudó solo para la enumeración, pero sospecho que ayudará para las compilaciones.
RickNZ
25

NTFS ahorra tiempo de acceso a archivos cada vez. Puede intentar deshabilitarlo: "conjunto de comportamiento fsutil disablelastaccess 1" (reiniciar)

Agent_L
fuente
66
Pruebas que afeitaron 4 segundos menos que las 36 anteriores. Todavía abominable en comparación con .6 segundos en mi máquina virtual Linux
b7kich
21

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

Además, en Windows, generalmente tiene escáneres de virus, así como herramientas de restauración y búsqueda del sistema que pueden arruinar sus tiempos de compilación por completo si monitorean su carpeta Buid 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 está realmente interesado.

Comunidad
fuente
17

Personalmente, encontré que ejecutar una máquina virtual de Windows en Linux logró eliminar una gran parte de la lentitud de IO en Windows, probablemente porque Linux VM estaba haciendo mucho almacenamiento en caché que Windows no.

Al hacerlo, pude acelerar los tiempos de compilación de un gran proyecto C ++ (250Kloc) en el que estaba trabajando, desde unos 15 minutos hasta unos 6 minutos.

bfrog
fuente
¿seriamente? ¿Quiere decir que debería probarlo para usar una máquina virtual como máquina de desarrollo? Suena extraño ... ¿qué VM usas?
Martin Booka Weser
8
Probé el escenario anterior con una VM Ubuntu 11.04 ejecutándose dentro de mi estación de trabajo de Windows 7. 0,6 seg para el linux VM, 36 seg para mi estación de trabajo de Windows
b7kich
2
Si usa virtualbox y configura una unidad compartida, esencialmente puede acelerar sus compilaciones de forma gratuita.
orlp
La redacción aquí es muy confusa, pero supongo que significa una máquina virtual alojada en Windows que ejecuta Linux, no una máquina virtual que ejecuta Windows alojada en Linux ... lo cual es interesante, pero mi primera lectura literal de esto sugirió que ejecutar Windows en una VM alojada en Linux para compilar condujo a velocidades más rápidas que ejecutar Windows de forma nativa, y eso hubiera sido realmente algo.
underscore_d
@underscore_d, he visto algo así , donde Windows en una VM se ejecuta mucho más rápido que en hardware real. Probablemente porque Linux le dijo a Windows que está operando en un disco real, mientras que Linux, de hecho, hizo un almacenamiento en caché agresivo detrás de escena. La instalación de Windows en la máquina virtual también fue increíblemente rápida, por ejemplo. Esto fue en los días de XP, pero me sorprendería si hubiera mucha diferencia hoy.
Prof. Falken
17

La dificultad para hacerlo se debe al hecho de que C ++ tiende a extenderse 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 hacer un compilador de C ++ realmente rápido para Windows, intente mantener todo en RAM y toque el sistema de archivos lo menos posible.

Así es también como hará una cadena de compilación C ++ de Linux más rápida, pero es menos importante en Linux porque el sistema de archivos ya está haciendo mucho ajuste por usted.

La razón de esto se debe a la cultura Unix: históricamente, el rendimiento del sistema de archivos ha sido una prioridad mucho más alta en el mundo 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.

  1. 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 han sido a través de mejoras de hardware. Es decir, si el rendimiento es lento, puede solucionar 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 quisiera mejorar el rendimiento, primero lo abordaría en software (más barato y más fácil) y en 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 formas novedosas de mejorar el rendimiento.

  2. Unix tiende hacia muchos archivos pequeños; Windows tiende a unos pocos (o un solo) gran archivo.

    Las aplicaciones Unix tienden a manejar 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 ese es un pequeño porcentaje.

    Como resultado, Unix tiene un sistema altamente optimizado para abrir y cerrar archivos, escanear directorios, etc. La historia de los trabajos de investigación de Unix abarca décadas de optimizaciones del sistema de archivos que piensan mucho en mejorar el acceso a directorios (búsquedas y escaneos de directorios completos), apertura inicial de archivos, etc.

    Las aplicaciones de Windows tienden a abrir un archivo grande, mantenerlo abierto durante mucho tiempo, cerrarlo cuando haya terminado. 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 rapidez con 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. Heck, el mejor sistema de procesamiento de texto para Unix (TeX / LaTeX) lo alienta a colocar cada capítulo en un archivo diferente y # incluirlos todos juntos.

  3. 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: los usuarios solo se preocupan por lo que ven y ven la interfaz de usuario. Por lo tanto, se gasta más energía en mejorar la interfaz de usuario que el rendimiento.

  4. 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?

    No creo en las teorías de 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 reloj. (Es por eso que el precio de las acciones de miles de empresas se ve afectado si MS envía un sistema operativo tarde o si Intel pierde una fecha de lanzamiento del chip). Esto significa que hay un incentivo para resolver problemas de rendimiento diciéndole a la gente que compre nuevo hardware; no mejorando el verdadero problema: sistemas operativos lentos. Unix proviene de la academia, donde el presupuesto es limitado y puedes obtener tu doctorado inventando una nueva forma de acelerar los sistemas de archivos; rara vez alguien en la academia obtiene puntos por resolver un problema emitiendo una orden de compra.

    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 brinda a los académicos acceso 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 busque la historia de los documentos de Osterhaus, Henry Spencer u otros. Heck, uno de los debates más grandes (y más agradables de ver) en la historia de Unix fue el ida y vuelta entre Osterhaus y Selzer http://www.eecs.harvard.edu/margo/papers/usenix95-lfs/supplement/rebuttal. html No ves que ese tipo de cosas sucedan en el mundo de Windows. Es posible que veas vendedores que se superan entre sí, pero eso parece ser mucho más raro últimamente, ya que la innovación parece estar a nivel del cuerpo de los estándares.

Así lo veo yo.

Actualización: si observa las nuevas cadenas de compiladores que están saliendo de Microsoft, será muy optimista porque gran parte de lo que están haciendo hace que sea más fácil mantener toda la cadena de herramientas en RAM y repetir menos trabajo. Cosas muy impresionantes.

TomOnTime
fuente
66
Decir que la razón es "cultural, no técnica" realmente no responde la pregunta. Obviamente, hay una o más razones técnicas subyacentes por las que ciertas operaciones son más lentas en Windows que en Linux. Ahora, los problemas culturales pueden explicar por qué las personas tomaron decisiones técnicas que tomaron; pero este es un sitio técnico de preguntas y respuestas. Las respuestas deben cubrir las razones técnicas por las cuales un sistema es más lento que el otro (y qué se puede hacer para mejorar la situación), no conjeturas no demostrables sobre la cultura.
Brian Campbell
Esto no parece tener mucha información técnica. Principalmente circunstancial. Creo que la única forma en que obtendremos información técnica real es observando las diferencias entre los dos compiladores, sistemas de compilación, etc.
surfasb
Las aplicaciones de Windows tienden a abrir un archivo grande, manténgalo abierto durante mucho tiempo : muchas aplicaciones UNIX hacen esto. Servidores, mis Emacs, etc.
Noufal Ibrahim
No creo que emacs mantenga los archivos abiertos durante mucho tiempo, sea grande o pequeño. Ciertamente no escribe en el medio del archivo, actualizándolo como lo haría una base de datos.
TomOnTime
... y los servidores tampoco hacen eso. Sus características en los sistemas * nix generalmente se dividen en muchos módulos pequeños, siendo el núcleo del servidor esencialmente un shell vacío.
espectros
7

Enlace incremental

Si la solución VC 2008 está configurada como proyectos múltiples con salidas .lib, debe configurar "Usar entradas de dependencia de biblioteca"; esto hace que el enlazador se vincule directamente con los archivos .obj en lugar del .lib. (Y en realidad hace que sea 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 debería hacer otra copia del directorio en la máquina fuente. (Todavía puede ser lento, pero podría deberse a cualquier cantidad de cosas: fragmentación del disco, nombres de archivo cortos, servicios en segundo plano, etc.) Aunque creo que los problemas de dir /srendimiento tienen más que ver con escribir la salida que con medir el archivo real Rendimiento transversal. Even dir /s /b > nules lento en mi máquina con un gran directorio.

MSN
fuente
6

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 donde el código dependiente de la plataforma es absolutamente necesario. Usamos Mercurial, no git, por lo que no se aplica la "Linuxness" de git. Obtener cambios desde el repositorio central lleva una eternidad en Windows en comparación con Linux, pero tengo que decir que nuestras máquinas con Windows 7 funcionan mucho mejor 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 lento 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 de Windows ya ni siquiera se molestan en hacer compilaciones incrementales: descubren que hacer una compilación de unidad es más rápido.

Por cierto, si desea disminuir drásticamente la velocidad de compilación en Windows, sugeriría la mencionada construcción de la unidad. Implementar correctamente en el sistema de compilación es complicado (lo hice para nuestro equipo en CMake), pero una vez hecho esto, acelera automáticamente las cosas para nuestros servidores de integración continua. Dependiendo de cuántos binarios está escupiendo su sistema de construcción, puede obtener una mejora de 1 a 2 órdenes de magnitud. Su experiencia puede ser diferente. En nuestro caso, creo que aceleró las compilaciones de Linux tres veces y las de Windows en un factor de 10, pero tenemos muchas bibliotecas y ejecutables compartidos (lo que disminuye las ventajas de una compilación de unidad).

Átila Neves
fuente
5

¿Cómo construyes tu gran proyecto multiplataforma? Si está utilizando archivos MAKE comunes para Linux y Windows, podría degradar fácilmente el rendimiento de Windows en 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 sh.exeproceso 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

.ONESHELL:

debería resolver el problema, pero esta característica (actualmente) no es compatible con Windows make. ¡Así que reescribir las recetas para que estén en líneas lógicas únicas (por ejemplo, agregando; \ o \ al final de las líneas del editor actual) funcionó muy bien!

V15I0N
fuente
4

En mi humilde opinión, se trata de rendimiento de E / S de disco. El orden de magnitud sugiere que muchas de las operaciones van al disco en Windows, mientras que se manejan en la memoria en Linux, es decir, Linux se almacena mejor en caché. Su mejor opción en Windows será mover sus archivos a un disco, servidor o sistema de archivos rápido. Considere comprar una unidad de estado sólido o mover sus archivos a un disco RAM o un 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 sugirió anteriormente atravesando el árbol de directorio de cromo:

  • Windows Home Premium 7 (8 GB de 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

Apagué las marcas de tiempo de acceso, mi escáner de virus y aumenté la configuración del administrador de caché en Windows (> 2 Gb de RAM), todo sin mejoras notables. El hecho es que, desde el primer momento, Linux funcionó 50 veces mejor que Windows con una cuarta parte de la RAM.

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

b7kich
fuente
1
Después de hacer algunos de los ajustes que describo en mi respuesta para Windows, ejecutar la prueba "ls -lR" anterior en el árbol de cromo tomó 19.4 segundos. Si uso "ls -UR" en su lugar (que no obtiene estadísticas de archivo), el tiempo cae a 4,3 segundos. Mover el árbol a un SSD no aceleró nada, ya que el sistema operativo almacena en caché los datos del archivo después de la primera ejecución.
RickNZ
¡Gracias por compartir! A pesar de una mejora sólida del factor 10 en comparación con el escenario 'listo para usar' de Windows 7, sigue siendo un factor 10 peor que Linux / ext4.
b7kich
Pensé que el objetivo del OP era mejorar el rendimiento de Windows, ¿verdad? Además, como publiqué anteriormente, "dir / s" se ejecuta en aproximadamente un segundo.
RickNZ
3

Intenta usar jom en lugar de nmake

Consíguelo aquí: https://github.com/qt-labs/jom

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

GNU lo hace listo para usar gracias a la opción -j, que podría ser una razón de su velocidad frente a Microsoft nmake.

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

OpenNingia
fuente
1

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

Antes de que me doliera la cabeza porque la velocidad de compilación se redujo en un factor de aproximadamente 10 cuando abrí una conexión VPN en paralelo. En este caso, todas estas búsquedas de 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, mientras tanto, podría haber cambiado en la última versión de MinGW.

V15I0N
fuente
0

Recientemente pude archivar otra forma de acelerar la compilación en aproximadamente un 10% en Windows usando Gnu make reemplazando mingw bash.exe con la versión de win-bash

(El win-bash no es muy cómodo con respecto a la edición interactiva).

V15I0N
fuente