¿Qué compiladores x86 C++ son multiproceso por sí mismo?

Ahora, casi todos los usuarios tienen 2 o 4 núcleos en el escritorio (y en un gran número de computadoras portátiles). Los usuarios avanzados tienen 6-12 núcleos con amd o i7.¿Qué compiladores x86 C++ son multiproceso por sí mismo?

¿Qué compiladores x86/x86_64 C/C++ pueden usar varios hilos para hacer la compilación?

Ya hay soluciones similares a 'make -j N', pero a veces (para -fwhole-program o -ipo) hay el último paso grande y lento, que comenzó de forma secuencial.

¿Alguno de estos puede: GCC, compilador Intel C++, compilador Borland C++, Open64, LLVM/GCC, LLVM/Clang, compilador Sun, MSVC, OpenWatcom, Pathscale, PGI, TenDRA, Digital Mars?

¿Existe algún límite superior de número de subprocesos para los compiladores, que son multiproceso?

Gracias!

Fuente

2010-12-13 osgx

Para Visual C++, no estoy al tanto de si realiza alguna compilación paralela (no lo creo). Para las versiones posteriores a Visual Studio 2005 (es decir, Visual C++ 8), los proyectos dentro de una solución se construyen en paralelo hasta donde lo permite el gráfico de dependencia de la solución.

Fuente

2010-12-13 15:01:25

Como dices, los proyectos individuales dentro de una solución se compilan en paralelo. Un solo proyecto se compila en un solo núcleo, de un solo subproceso. El paso de enlace tiene un solo subproceso. –

@John - gracias por la confirmación –

Algunos sistemas de compilación pueden compilar módulos independientes en paralelo, pero los propios compiladores siguen siendo de un solo subproceso. No estoy seguro de que haya algo que ganar haciendo que el compilador tenga múltiples subprocesos. La fase de compilación que más tiempo consume es procesar todas las #include dependencias y tienen para procesarse secuencialmente debido a posibles dependencias entre los diversos encabezados. Las otras fases de compilación dependen en gran medida del resultado de las fases anteriores, por lo que se obtienen pocos beneficios con el paralelismo.

Fuente

2010-12-13 15:04:54 Ferruccio

El más lento es la optimización con alto nivel (O2, O3) y la optimización -ipo. – osgx

La generación de código y la optimización global también requieren una gran fracción de tiempo, y * pueden * realizarse en paralelo. – ybungalobill

¿No podría tener programas multiproceso que desarrollen una cola segura para subprocesos de incluir dependencias en orden? Su respuesta no tiene mucho sentido. –

Las versiones más nuevas de Visual Studio pueden compilar distintas unidades de traducción en paralelo. Ayuda si su proyecto usa muchos archivos de implementación (como .c, .cc, .cpp).

MSDN Page

Fuente

2010-12-13 15:21:12 watson1180

¿A qué versión (s) del compilador de Visual C++ se refiere esto? No sabía que la compilación paralela dentro de un proyecto era compatible. –

es como 'make -j N' solución, por lo que no es una respuesta – osgx

VS 2008 y 2010 admiten compilación paralela. Verifica el enlace. – watson1180

No es realmente posible a la multi-proceso de la etapa de enlace. Puede haber cierto grado de multi-threading posible, pero es poco probable que proporcione un gran impulso al rendimiento. Como tal, muchos sistemas de compilación simplemente dispararán un proceso separado para archivos separados. Una vez que estén todos compilados, como se verá, ejecutarán un enlace largo con un solo hilo. Por desgracia, como digo, hay muy poco que puede hacer al respecto :(

Fuente

2010-12-13 15:31:53 Goz

La etapa de enlace es bastante pequeña (en términos de tiempo) en proyectos grandes, donde se usa el modo '-O3' o incluso' -ipo' o '-whole-program --combine'. – osgx

P.E. hay un archivo en mysql, cuya compilación puede durar hasta varias horas con gcc. Este es un analizador SQL, un solo archivo de 1 MB. El tiempo de enlace es pequeño, pero el tiempo de optimización es enorme. – osgx

IIRC el enlazador incluido con el compilador Digitalmars C/C++ tiene múltiples hilos (y está escrito en ASM!) Con el efecto final de ser uno de los enlazadores más rápidos del mundo. Puede que no proporcione aceleraciones lineales, pero puede recortar varios minutos de construcciones grandes. – BCS

La compilación multiproceso no es realmente útil ya que los sistemas de compilación (Make, Ninja) iniciarán varias unidades de compilación a la vez. Y como declaró Ferrucio, concurrente compilación es realmente difícil de implementar.

vinculación multiproceso puede sin embargo ser útil (/ .a resolución de lectura y el símbolo .o concurrente.) ya que esto será muy probablemente el último paso de generación.

Gnu oro enlazador puede haber multiproceso, con la implementación de LLVM ThinLTO: https://clang.llvm.org/docs/ThinLTO.html

Fuente

2017-04-28 12:36:04 Salamandar

"La compilación multiproceso no es realmente útil": puede ser muy útil si su tiempo de compilación está dominado por un único archivo C++ (que he experimentado varias veces con OSS y proyectos comerciales) o cuando hace compilación incremental después de cambiar aa fila india. La compilación paralela ha estado en LLVM devmeetings para que la gente lo considere. – yugr

"El enlazador Gnu Gold puede ser multiproceso": tenga en cuenta que [Documento dorado] (https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34417.pdf) afirma que hubo sin aceleración para enlaces multiproceso. – yugr

@yugr La mayor mejora en la aceleración proviene de ThinLTO como dije. Pero (lo he omitido hace algunos meses), esta aceleración solo supera a la LTO no delgada. – Salamandar

Gcc tiene -flto=n o -flto=jobserver para hacer que el paso de enlace (que con LTO optimiza y generación de código) sea paralelo. De acuerdo con la documentación, estos han estado disponibles desde la versión 4.6, aunque no estoy seguro de qué tan bueno fue en esas primeras versiones.

Fuente

2017-04-28 13:05:35

¿De qué versión? ¿Dónde está documentado? Si es cierto que [WHOPR! = LTO] (https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html) y -flto pueden tener un resultado mejor (o simplemente diferente) que -flto = n? – osgx

@osgx Agregué un enlace a la documentación. No sé si hay alguna diferencia en el código generado entre '-flto' y' -flto = 42'. –

Go 1.9 compilador dice tener:

Compilación paralelo

El compilador Ir ahora es compatible con la compilación de las funciones de un paquete en paralelo, aprovechando las múltiples núcleos. Esto es adicional al soporte existente del comando go para la compilación paralela de paquetes separados.

pero, por supuesto, que compila Go, no C++

No puedo nombrar a cualquier compilador de C++ haciendo lo mismo, incluso en octubre de 2017. Pero supongo que el multi-hilo compilador Ir muestra que múltiples los compiladores C o C++ enhebrados son (en principio) posibles. Pero son pocos, y crear nuevos es huge work, y prácticamente tendrá que comenzar ese esfuerzo desde cero.

Fuente

2017-10-28 13:10:19

¿Qué compiladores x86 C++ son multiproceso por sí mismo?

Respuesta

Cuestiones relacionadas