¿Cuánto debería preocuparme por el compilador Intel C++ que emite un código subóptimo para AMD?

Question

Siempre hemos sido una tienda de Intel. Todos los desarrolladores usan máquinas Intel, la plataforma recomendada para los usuarios finales es Intel, y si los usuarios finales quieren ejecutar AMD, es su punto de observación. Tal vez el departamento de pruebas tenía una máquina AMD en algún lugar para verificar que no enviamos nada completamente roto, pero eso fue todo.

Hasta hace unos años solo usábamos el compilador MSVC y dado que realmente no ofrece muchas opciones de ajuste del procesador más allá del nivel SSE, a nadie le preocupaba demasiado si el código podría favorecer a un proveedor x86 sobre otro . Sin embargo, más recientemente hemos estado usando mucho el compilador de Intel. Definitivamente, nuestro material obtiene importantes beneficios de rendimiento (en nuestro hardware Intel), y sus capacidades de vectorización significan menos necesidad de ir a asm/intrinsics. Sin embargo, la gente está empezando a ponerse un poco nerviosa sobre si el compilador de Intel realmente no puede estar haciendo un buen trabajo para el hardware de AMD. Ciertamente, si ingresa a las bibliotecas Intel CRT o IPP, verá muchas consultas de cpuid para configurar, al parecer, tablas de salto para funciones optimizadas. Sin embargo, parece poco probable que Intel se tome la molestia de hacer algo bueno por los chips de AMD.

¿Alguien con alguna experiencia en esta área puede comentar si es un gran problema o no en la práctica? (Todavía tenemos que realizar pruebas de rendimiento en AMD).

Actualización 2010-01-04: Bueno, la necesidad de soportar AMD nunca se hizo lo suficientemente concreta como para que pudiera hacer ninguna prueba yo mismo. Hay algunas lecturas interesantes sobre el problema here, here y here embargo.

actualización 2010-08-09: Parece la solución Intel-FTC tiene algo que decir sobre este tema - ver sección de this article "Los compiladores y trucos sucios".

Answer 1

Compre una caja AMD y ejecútela en eso. Parece ser lo único responsable, en lugar de confiar en extraños en Internet;)

Aparte de eso, creo que parte del juicio de AMD contra Intel se basa en la afirmación de que el compilador de Intel produce específicamente código que funciona de manera ineficiente en Procesadores AMD. No sé si eso es cierto o no, pero AMD parece creerlo.

Pero incluso si no lo hacen deliberadamente, no hay duda de que el compilador de Intel se optimiza específicamente para los procesadores Intel y nada más.

Cuando eso se dice, dudo que haga una gran diferencia. Las CPU de AMD todavía se beneficiarían de toda la auto-vectorización y otras características inteligentes del compilador.

Answer 2

Definitivamente estoy diciendo lo obvio, si el rendimiento es crucial para su aplicación, entonces será mejor que haga algunas pruebas en todas las combinaciones de hardware/compilador. No hay garantías Como personas externas, solo podemos darte nuestras conjeturas/sesgos. Su software puede tener características únicas que son diferentes a lo que hemos visto.

Mi experiencia:

Yo solía trabajar en Intel, y ha desarrollado una aplicación interna (C++), donde el rendimiento era crítica. Intentamos usar el compilador C++ de Intel y siempre bajo gcc ejecutado, incluso después de ejecutar el perfil, recompilar usando la información perfilada (que icc supuestamente utiliza para optimizar) y volver a ejecutar en el mismo conjunto de datos (esto fue en 2005) -2007, las cosas pueden ser diferentes ahora). Por lo tanto, en función de mi experiencia, es posible que desee probar gcc (además de icc y MSVC), es posible obtener un mejor rendimiento de esa manera y dejar de lado la cuestión.No debería ser demasiado difícil cambiar los compiladores (si su proceso de compilación es razonable).

Ahora trabajo en una compañía diferente, y la gente de TI hace extensas pruebas de hardware, y durante un tiempo el hardware Intel y AMD fue relativamente comparable, pero la última generación de hardware Intel superó significativamente a AMD. Como resultado, creo que compraron cantidades significativas de CPU de Intel y recomendaron lo mismo para nuestros clientes que manejan nuestro software.

Pero, de vuelta a la pregunta de si el compilador de Intel se dirige específicamente al hardware de AMD para ejecutarse lentamente. Dudo que Intel se moleste con eso. Podría ser que ciertas optimizaciones que utilizan el conocimiento sobre el funcionamiento interno de la arquitectura de la CPU Intel o los conjuntos de chips podrían correr más lento en el hardware de AMD, pero dudo que se dirijan específicamente al hardware de AMD.

Answer 3

Lo siento si presionas mi botón general.

Esto es sobre el tema de la optimización de bajo nivel, por lo que solo importa para el código que 1) el contador del programa pase mucho tiempo, y 2) el compilador realmente vea. Por ejemplo, si la PC pasa la mayor parte del tiempo en rutinas de biblioteca que no compila, no debería importar mucho.

Sea o no las condiciones 1 & 2 se cumplen, aquí está mi experiencia de cómo va optimización:

varias iteraciones de muestreo y fijación se realizan. En cada uno de estos, se identifica un problema y la mayoría de las veces no se trata de dónde está el contador del programa. Más bien es que hay llamadas de función en los niveles medios de la pila de llamadas que, dado que el rendimiento es primordial, podrían ser reemplazadas. To find them quickly, I do this.

Tenga en cuenta que si hay una instrucción de llamada de función que está en la pila durante una fracción significativa del tiempo de ejecución, ya sea en unas largas invocaciones o en muchas cortas, esa llamada es responsable de esa fracción de tiempo, por lo que eliminarlo o ejecutarlo con menos frecuencia puede ahorrarle mucho tiempo. Y, ese ahorro excede por mucho cualquier optimización de bajo nivel.

El programa ahora puede ser muchas veces más rápido de lo que era para empezar. Nunca he visto ningún programa de buen tamaño, sin importar lo cuidadosamente escrito, que no pueda beneficiarse de este proceso. Si el proceso no se ha realizado, no debe suponerse que la optimización de bajo nivel es la única forma de acelerar el programa.

Después de este proceso se ha hecho hasta el punto en que simplemente no se puede hacer más, y si las muestras muestran que la PC está en el código que ve el compilador, la optimización de bajo nivel puede hacer la diferencia.

Answer 4

Lo que hemos visto es que siempre que el compilador de Intel debe realizar una elección de tiempo de ejecución sobre el conjunto de instrucciones disponible, si no reconoce una CPU Intel, va en su código "estándar" (que, como era de esperar, puede no ser óptimo).

Tenga en cuenta que incluso si utilicé la palabra "compilador" anterior, esto ocurre principalmente en las bibliotecas provistas (precompiladas) y en las características intrínsecas que verifican el conjunto de instrucciones y llaman al mejor código.

Answer 5

No tiene sentido preocuparse si no puede actuar. Las acciones posibles son: No comprar AMD o usar un compilador diferente. Entonces las cosas obvias son:

(1) Compre una caja AMD y mida la velocidad del código compilado con el compilador Intel. ¿Es lo suficientemente rápido? Si es así, ya terminaste, puedes comprar AMD, no te preocupes.

(2) En caso negativo, compile el código con un compilador diferente y ejecútelo en el recuadro AMD. ¿Es lo suficientemente rápido? Si no, has terminado, no puedes comprar AMD, no te preocupes.

(3) En caso afirmativo: ejecute el mismo código en una caja de Intel. ¿Es lo suficientemente rápido? Si es así, ya terminaste, puedes comprar AMD pero tienes que cambiar los compiladores, no te preocupes.

(4) En caso negativo: Las posibilidades son: No compre AMD, saque todas las computadoras Intel o compile con dos compiladores diferentes. Elegir uno.

Answer 6

He experimentado directamente una paralización intencionada de la tecnología cuando un proveedor intentó evitar que un producto Lotus llegue al mercado antes de su oferta. Una tecnología funcional estaba disponible, pero Lotus tenía prohibido usarla. Ah bien ...

Hace unos años, había blogs que mostraban a los usuarios que parchar un solo byte en el compilador de Intel hacía que emitiera un código "óptimo" que no estaba paralizado cuando se usaba en AMD. No he buscado esas entradas de blog en años.

Me inclino a creer que ese comportamiento competitivo continúa. No tengo otra evidencia para ofrecer.

Answer 7

En el momento en que se inició este thread, Microsoft C++ entró en default a la generación de código, que en algunos casos era bueno para AMD y malo para Intel. Sus compiladores más recientes usan de manera predeterminada la opción de fusión, lo que es bueno para ambos, particularmente después de que ambas marcas de CPU resolvieron sus peculiares errores de rendimiento. Cuando trabajé por primera vez en Intel, sus compiladores reservaron algunas optimizaciones para configuraciones de arquitectura específicas de Intel. Supongo que podría haber sido un tema de algunas deposiciones de la FTC, aunque no apareció en mis 10 horas de testimonio, y la práctica ya estaba en camino a la salida debido a la convergencia de los requisitos de optimización entre los modelos de CPU actualizados y el necesidad de un uso más productivo del tiempo de desarrollo del compilador. Si usó uno de esos compiladores obsoletos en una CPU Intel actualizada, es posible que vea algunas de las mismas deficiencias de rendimiento.