ifort compiler c++ linux compiler-construction boost benchmarking

compiler - ¿Alguien aquí ha comparado el compilador Intel C++ y GCC?



intel c++ compiler download (9)

No estoy seguro de si debería publicar esta pregunta aquí, porque este parece ser un sitio web orientado a la programación.

De todos modos, creo que debe haber algunos gurús aquí que lo saben.

Ahora tengo un servidor AMD Opteron que ejecuta CentOS 5. Quiero tener un compilador para un programa bastante grande basado en C ++ Boost. ¿Qué compilador debería elegir?

Aquí hay un PDF interesante que compara una cantidad de compiladores.

El equipo de MySQL publicó una vez que icc les dio un 10% de aumento de rendimiento sobre gcc. Trataré de encontrar el enlace.

En general, he encontrado que los compiladores ''nativos'' funcionan mejor que gcc en sus respectivas plataformas

editar: Estaba un poco apagado. Las ganancias típicas fueron del 20-30%, no del 10%. Algunos casos de borde angosto duplicaron el rendimiento. http://www.mysqlperformanceblog.com/files/presentations/LinuxWorld2004-Intel.pdf

Espero que esto ayude más que lastima :)

Hice un pequeño tiroteo en el compilador hace más de un año, y me estoy quedando sin memoria.

  1. GCC 4.2 (Apple)
  2. Intel 10
  3. GCC 4.2 (Apple) + LLVM

Probé múltiples programas de procesamiento de señales de audio pesadas que había escrito.

Tiempos de compilación: el compilador de Intel fue, con mucho, el compilador más lento: más de ''2 veces más lento'' que otro citado.

GCC manejó las plantillas profundas muy bien en comparación con Intel.

El compilador de Intel generó enormes archivos de objetos.

GCC + LLVM arrojó el binario más pequeño.

El código generado puede tener una variación significativa debido a la construcción del programa, y ​​donde se podría usar SIMD.

Por la forma en que escribo, descubrí que GCC + LLVM generaba el mejor código. Para los programas que había escrito antes tomé en serio la optimización (como escribí), Intel generalmente era mejor.

Los resultados de Intel variaron; manejó algunos programas mucho mejor, y algunos programas mucho peores. Manejó muy bien el procesamiento en bruto, pero le doy la torta a GCC + LLVM porque cuando se lo coloca en el contexto de un programa más grande (normal) ... lo hizo mejor.

Intel ganó por la caja, la cantidad de números en enormes conjuntos de datos.

GCC solo generó el código más lento, aunque puede ser tan rápido con mediciones y nano-optimizaciones. Prefiero evitarlos porque el viento puede cambiar de dirección con la próxima versión del compilador, por así decirlo.

Nunca medí los programas mal escritos en esta prueba (es decir, los resultados superaron las distribuciones de las bibliotecas de rendimiento popular).

Finalmente, los programas fueron escritos durante varios años, utilizando GCC como compilador primario en ese momento.

Actualización: también estaba habilitando optimizaciones / extensiones para Core2Duo. Los programas fueron lo suficientemente limpios para permitir el aliasing estricto.

Muchas optimizaciones que el compilador de Intel realiza rutinariamente requieren una sintaxis de fuente específica y el uso de -O3 -ffast-math para gcc. Lamentablemente, el componente optimizaciones -funsafe-math-optimizations de -ffast-math -O3 -march = native ha resultado ser incompatible con -fopenmp, por lo que debo dividir mis archivos de origen en grupos nombrados con las diferentes opciones en Makefile. Hoy entré en una falla donde una compilación de g ++ con -O3 -ffast-math -fopenmp -march = native podía escribir en la pantalla pero no redirigir a un archivo. Una de las diferencias más notorias en mi opinión es la optimización por icpc solo de std :: max y min donde gcc / g ++ quiere que fmax | min [f] con -ffast-math cambie su significado fuera del estándar.

Solía ​​trabajar en un sistema de procesamiento de señal bastante grande que se ejecutaba en un clúster grande. Solíamos contar con el cálculo pesado de las matemáticas, el compilador de Intel nos dio un 10% menos de carga de CPU que GCC. Eso es muy poco científico, pero fue nuestra experiencia (eso fue hace unos 18 meses).

Lo que hubiera sido interesante es si hubiésemos podido usar también las bibliotecas matemáticas de Intel que usan su conjunto de chips de manera más eficiente.

Supongo que varía según el código, pero con la base de código en la que estoy trabajando ahora, ICC 11.035 da una mejora de casi 2x sobre gcc 4.4.0 en un Xeon 5504.

Opciones de icc: -O2 -fno-alias
Opciones de gcc: -O3 -msse3 -mfpmath=sse -fargument-noalias-global

Las opciones son específicas solo del archivo que contiene el código de cálculo intensivo, donde sé que no hay aliasing. Código de un solo subproceso con un bucle anidado de 5 niveles.

Aunque la autovectorización está habilitada, ninguno de los compiladores genera código vectorizado (no es un error de los compiladores)

Actualización (27/02/2015): Al optimizar algunos códigos geofísicos (Q2, 2013) para ejecutar en Sandy Bridge-E Xeons, tuve la oportunidad de comparar el rendimiento de ICC 11.1 con GCC 4.8.0, y ahora GCC estaba generando código más rápido que ICC. El código utilizado hizo uso de los intrínsecos de AVX y sí utilizó instrucciones vectorizadas de 8 vías (el compilador no autorizó el código correctamente debido a ciertos requisitos de diseño de datos). Además, la implementación LTO de GCC (con el núcleo IR incrustado en los archivos .o) fue mucho más fácil de administrar que en ICC. GCC con LTO funcionaba aproximadamente 3 veces más rápido que ICC sin LTO. No puedo encontrar los números ahora para GCC sin LTO, pero recuerdo que todavía era más rápido que ICC. De ninguna manera es una declaración general sobre el desempeño de ICC, pero los resultados fueron suficientes para que podamos seguir adelante con GCC 4.8. *.

Esperando ansiosos GCC 5.0 ( http://www.phoronix.com/scan.php?page=article&item=gcc-50-broadwell )!

Usamos el compilador Intel en nuestro producto (DB2), en Linux y Windows IA32 / AMD64, y en OS X (es decir, todos nuestros puertos de la plataforma Intel excepto SunAMD).

No sé los números, pero el rendimiento es lo suficientemente bueno como para que nosotros:

  • pagar por el compilador que me dicen que es muy caro.
  • en vivo con los tiempos de compilación 2 veces más lentos (principalmente debido al tiempo que pasa adquiriendo licencias antes de que se permita ejecutar).

Utilicé UnixBench (v. 5.1.3) en un openSUSE 12.2 (kernel 3.4.33-2.24-default x86_64), y lo compilé primero con GCC, y luego con el compilador de Intel.

Con 1 copia en paralelo, UnixBench compilado con Intel es aproximadamente un 20% más rápido que la versión compilada con GCC. Sin embargo, esto oculta enormes diferencias. Dhrystone es aproximadamente un 25% más lento con el compilador de Intel, mientras que Whetstone corre 2 veces más rápido.

Con 4 copias de UnixBench ejecutándose en paralelo, la mejora del compilador de Intel sobre GCC es solo del 7%. Nuevamente Intel es mucho mejor en Whetstone (> 200%) y más lento en Dhrystone (aproximadamente 20%).