¿Los compiladores de Intel son realmente mejores que los de Microsoft? [cerrado]

Hace años, me sorprendió cuando descubrí que Intel vende compiladores compatibles con Visual Studio. Lo probé en particular para C / C ++, así como fantásticas herramientas de diagnóstico. Pero el código simplemente no era computacionalmente intensivo para notar la diferencia. La única impresión fue: ¿Intel realmente lo hizo por mí en este momento? Guau, herramientas increíbles con una resolución de nanosegundos, increíble. Pero el juicio terminó y el equipo nunca consideró seriamente una compra.

Según su experiencia, si el costo de la licencia no importa, ¿qué proveedor es el ganador?

No es una pregunta amplia o vaga ni un intento de desencadenar una guerra santa. Este tipo de pregunta es sobre dos herramientas muy visibles. A nadie le gusta cuando las herramientas tienen misterios o sorpresas. Y las elecciones entre las mejores y las mejores son siempre el dolor. También entiendo que la hierba siempre es un argumento más verde . Quiero escuchar todas las historias de "qué pasa si".

¿Qué sucede si Intel solo lo optimiza localmente para el paso de chip del mes, y no todos los objetivos de hardware funcionarán realmente tan bien como Microsoft compiló? ¿Qué sucede si el objetivo es el hardware AMD y todo se ralentizará sin motivo? O, por otro lado, ¿qué pasa si el hardware de Intel tiene tantas oportunidades imperceptibles que los escritores del compilador de Microsoft son demasiado lentos para adoptarlo y nunca lo implementan en el compilador? ¿Qué sucede si ambos son exactamente iguales, en realidad una única base de código envuelta en dos cajas diferentes y licenciada a ambos proveedores por una tienda de terceros?

Y así. Pero alguien sabe algunas respuestas.

ADVERTENCIA: Respuesta basada en experiencia propia - YMMV

Si el código es computacionalmente costoso, sí, definitivamente . He visto una mejora de más de 20 veces con el antiguo compilador Intel C ++ (ahora Intel Studio, si no recuerdo mal) en comparación con el compilador estándar Microsoft Visual C ++. Es cierto que el código estaba muy lejos de ser perfecto y eso puede haber jugado un papel (en realidad es por eso que nos molestamos en usar el compilador Intel, fue más fácil que refactorizar la base de código gigante), también la CPU utilizada para ejecutar el código era un Intel Core 2 Quad, que es la CPU perfecta para tal cosa, pero los resultados fueron impactantes. El compilador en sí contiene miles de formas de optimizar el código, incluida la orientación a una CPU específica en términos de, digamos, capacidades SSE . Realmente hace -O2/ -O3huir avergonzado. Y eso fueantes de usar el perfilador.

Tenga en cuenta que, sin embargo, activar optimizaciones realmente agresivas hará que la compilación tome bastante tiempo, dos horas para un proyecto grande no es imposible en absoluto. Además, con altos niveles de optimizaciones, existe una mayor probabilidad de que se manifieste un error en el código (esto también se puede observar con gcc -O3). Para un proyecto que conoces bien, esto podría ser una ventaja, ya que encontrarás y corregirás cualquier error que no hayas detectado antes, pero al compilar un desastre peludo, simplemente cruzas los dedos y rezas a los dioses x86.

Algo sobre el rendimiento en las máquinas AMD: no es tan bueno como las CPU Intel, pero sigue siendo mucho mejor que el compilador MS C ++ (de nuevo, según mi experiencia). La razón es que también puede apuntar a una CPU genérica con soporte SSE2 (por ejemplo). Entonces, las CPU AMD con SSE2 no serán discriminadas demasiado. Sin embargo, el compilador de Intel en la CPU de Intel realmente roba el espectáculo. Sin embargo, no todo es arcoiris dobles y unicornios brillantes. Ha habido algunas fuertes acusaciones sobre binarios que no se ejecutan en absoluto en CPUs que no son GenuineIntel y (este es admitido) otros fabricantes indujeron artificialmente un rendimiento inferior en las CPUs. También tenga en cuenta que esta es información de al menos 3 años atrás y su validez a partir de ahora es desconocida, PERO las nuevas descripciones de los productos les dan a los binarios una carta blanca para que funcionen tan lento como Intel considere conveniente en las CPU que no son Intel.

No sé de qué se trata Intel y por qué son tan buenas herramientas de cálculo numérico, pero eche un vistazo a esto también: http://julialang.org/ . Hay una comparación y si miras la última fila, MATLAB brilla al derrotar tanto al código C como a Julia , lo que me sorprende es que los autores piensan que la razón es la Biblioteca Kernel de Matemáticas de Intel .

Me doy cuenta de que esto se parece mucho a un anuncio del kit de herramientas del compilador de Intel, pero en mi experiencia realmente funcionó bien, e incluso la lógica simple dicta que los chicos que fabrican CPU deberían saber mejor cómo programar para ellos. En mi opinión, el compilador Intel C ++ exprime hasta el último bit de ganancia de rendimiento posible.

Intel Compiler tiene la reputación de producir código numérico muy eficiente:

https://stackoverflow.com/questions/1733627/anyone-here-has-benchmarked-intel-c-compiler-and-gcc

http://www.open-mag.com/754088105111.htm

http://www.freewebs.com/godaves/javabench_revisited/

Tenga en cuenta que no afirmo que sea el compilador más rápido que existe, pero ciertamente goza de una muy buena reputación de eficiencia. Tenga en cuenta que los autores de los binarios LAPACK "oficiales" para Windows usan el compilador Intel Fortran para compilarlos: http://icl.cs.utk.edu/lapack-for-windows/ y deben saber una o dos cosas sobre la eficiencia.

Intel C ++ tiene un par de ventajas sobre gcc además del generador de código. Ambos se derivan (en gran medida) del hecho de que se basa en el front-end EDG . Para bien o para mal, ambos se están erosionando (lentamente), por lo que las ventajas no son tan grandes como lo fueron antes.

La primera es que, por regla general, emite mensajes de error mucho mejores. Es posible que desee ver una comparación de mensajes de error entre Clang y gcc. Intel C ++ (junto con la mayoría de los otros basados ​​en el front-end EDG) ha estado emitiendo diagnósticos similares a los de Clang durante años.

En segundo lugar, es que el front-end EDG es tan conocido por su conformidad lingüística excepcionalmente buena como el generador de código Intel para producir código rápido. Casi por cualquier medida razonable, el front-end EDG proporciona una mejor conformidad con C ++ 98, 03 o (en las versiones actuales) C ++ 0x que cualquier otro compilador disponible.

Como dije, ambas ventajas se han erosionado en diversos grados con el tiempo. Las versiones recientes de gcc tienen una conformidad de lenguaje bastante decente. Clang tiene mensajes de error sustancialmente mejores, y también está haciendo un buen progreso hacia la implementación de todo el lenguaje C ++. Sin embargo, cuando llega al final, Intel C ++ sigue siendo mejor que cualquiera de los dos en ambos aspectos, y es un paquete único que hace la mayoría de las cosas bien en lugar de necesitar un compilador para un buen diagnóstico y otro para una mejor conformidad y generación de código.

Intentamos esto en el trabajo hace un tiempo. La mayor parte de nuestra base de código está en Delphi, pero tenemos una funcionalidad altamente computacionalmente intensiva que alguien pensó que sería una buena idea hacer en una DLL de C ++ en el pasado. Y uno de mis compañeros de trabajo había escuchado grandes cosas sobre el compilador de Intel, por lo que decidió probarlo. Reconstruimos la DLL en el compilador de Intel y ejecutamos algunas pruebas de velocidad, y los resultados lo sorprendieron tanto que pensó que debía estar haciendo algo mal.

La DLL tiene que calcular algunos problemas muy difíciles con los componentes de combinatoria y topología, que técnicamente están en la clase de dificultad NP-difícil si los hicimos "bien", pero utilizamos varias heurísticas para evitar el rendimiento de NP. Aun así, hay muchos cálculos numéricos. Y para las pruebas que ejecutamos, la diferencia entre el compilador VS y el compilador Intel estaba dentro de epsilon, o el compilador Intel era notablemente más lento, generalmente en algún lugar cercano al 20%. Y se mantuvo así sin importar los cambios que hizo en la configuración de compilación para intentar que el compilador Intel produzca código más rápido. Así que terminamos sin cambiar a eso.

Este es solo un ejemplo del mundo real, por supuesto. Su experiencia puede ser diferente.

En una aplicación integrada en la que trabajé una vez, una prueba de un compilador de Intel mostró que nos ahorraría tener que utilizar hardware nuevo con un rendimiento superior. El costo del nuevo hardware fue de alrededor de $ 10 / unidad, ventas proyectadas de 1 millón de unidades, Agregar costos de desarrollo y retrasos en los proyectos. La opción 2 era una optimización de perfil / micro, una base de código optimizada y bastante bien perfilada: resultados desconocidos, tiempo desconocido.

¿Qué crees que dijo el jefe cuando pedimos los fondos para comprar el compilador .......

Sin embargo, este fue un caso extremo muy afortunado y más raro: la salida de código 10% más rápida del compilador Intel nos empujó nuevamente al lado correcto del rendimiento. Si ya estuviéramos en el lado derecho, o hubiéramos superado el 10%, no habría hecho una diferencia. Si hubiéramos tenido los ingenieros, probablemente habríamos optimizado el código y ahorrado el giro del hardware y no necesitábamos el compilador Intel, pero el riesgo era alto y el compilador Intel funcionó más barato que el tiempo de ingeniería.

A fin de cuentas, diría que es una forma de micro optimización: no lo haga hasta que sepa que lo necesita, y luego, solo después de haber perfilado y encontrado la causa real de los problemas. Es una elección particularmente buena de su perfil muestra que es lento 'en todas partes' y no tiene cuellos de botella identificados.

Solo he encontrado tres ventajas:

1. Tiene soporte para funciones de CPU Intel más nuevas mucho antes que otros compiladores.

2. Es un gran compilador adicional para emitir advertencias y detectar problemas que otros compiladores pierden. GCC detecta algunas cosas que ICC no detecta, y viceversa. Visual Studio capta algunas cosas que ICC no detecta, y viceversa.

3. Hace un trabajo mucho mejor de bucles de paralelización automática (distribuyéndolos en múltiples subprocesos automáticamente) que cualquier otro compilador. No se beneficia mucho el código de esto, pero cuando tiene un código que lo hace, puede hacer una gran diferencia.

Usamos el compilador de inteligencia para cada proyecto crítico de rendimiento de nuestra base de código. Lo bueno de esto es que hace que la optimización del código sea realmente mantenible. En lugar de agregar manualmente __mm llamadas en todas partes, y decirle al compilador que precargue datos, todo lo cual será subóptimo en la próxima versión nuevamente, simplemente reorganice su código y gane una velocidad increíble.

A menudo, el código optimizado es más fácil de seguir que la mano optimizada, es más rápido que la mano optimizada, y cuando se libera un nuevo conjunto de instrucciones, el compilador utilizará ese conjunto de instrucciones. Es fantástico.

Lo mismo también aplica para el compilador de arm (desde arm, no intel), si su liberación en arm, hace un gran trabajo en la vectorización para usted.

Consulte esta página de referencia. En resumen, Intel gana.

Pero el margen puede no ser tan grande: si compila a 32 bits, y su sistema de compilación no puede soportar la optimización guiada por perfil, la ganancia es del orden del 10%. ¿Vale la pena tal mejora y los tiempos de compilación más largos?

Se ha dicho que Intel lanzó el Compilador Intel C ++ v13.0 para el sistema operativo Android, su primer intento de entregar un compilador optimizador C / C ++ diseñado específicamente para la plataforma móvil de Google.

Los desarrolladores pueden usar el compilador en sistemas basados ​​en Linux * para crear aplicaciones para dispositivos Android basados ​​en procesadores Intel, incluido el procesador Intel® Atom ™. El compilador Intel es compatible con GNU C ++ y las herramientas de desarrollo en el Android Native Development Kit (NDK). Tampoco puede usar el compilador en cualquier máquina de desarrollo. Ni Windows ni OS X son compatibles; las herramientas solo están certificadas para su uso con Ubuntu 10.04 o 11.04

La versión actual del NDK de Android utiliza la versión 4.6 de la cadena de herramientas Gnu Compiler Collection (GCC) de código abierto de forma predeterminada. Pero los compiladores de Intel incluyen muchas optimizaciones patentadas para sus propios chips, y a menudo pueden generar código ejecutable que funciona mejor que el producido por compiladores de terceros como GCC.