Esto no debería No sería demasiado sorprendente teniendo en cuenta algunos de los comentarios anteriores de Linus Torvald sobre optimizaciones del compilador y malas experiencias hace mucho tiempo con GCC, pero Linus Torvalds no está interesado en ver una opción ajustable de Kconfig para usar el nivel de optimización del compilador-O3 para construir el kernel de Linux sin cambios sustanciales. justificación.
Como escribí a principios de esta semana, hubo un parche propuesto para permitir una opción Kconfig para usar el nivel de optimización-O3 del compilador en lugar de-O2 al compilar el kernel de Linux. Tal opción en realidad ya existe en el núcleo, pero solo está expuesta para el puerto de la CPU ARC. Los parches propuestos debían hacer que esta opción”CC_OPTIMIZE_FOR_PERFORMANCE_O3″estuviera disponible para todas las arquitecturas, aunque con una bandera”experimental”claramente marcada. Hay interés entre algunos en las compilaciones de kernel-O3 para un mejor rendimiento y/o para rastrear fácilmente el código del kernel de Linux o los problemas del compilador al cambiar al nivel de optimización más agresivo.
No todos los desarrolladores ascendentes estaban de acuerdo con esta idea, ya que el nivel de optimización-O3 ya se puede configurar mediante la variable de entorno KCFLAGS y existe la posibilidad de que las optimizaciones del compilador introduzcan problemas, diferencias particularmente sutiles con optimizaciones agresivas del compilador que a veces pueden ser difíciles de rastrear.
Linus Torvalds esta tarde comentó que es efectivamente contra tener tal opción Kconfig. Tendría que estar realmente convencido por algunos datos duros del mundo real para mostrar sus beneficios, pero incluso entonces, como ha citado en el pasado, históricamente ha habido problemas conocidos del compilador con algunas optimizaciones. Los interesados siempre pueden usar”KCFLAGS=-O3″para lograr el mismo comportamiento, pero nuevamente cita el historial de problemas de optimización del compilador GCC.
Honestamente, eliminemos-O3 por completo.
Habilitarlo, y luego ni siquiera probar el resultado, es casi el *peor* caso posible. Eso es horrible.
El argumento de que”pero ARC lo usa”no es un argumento. Siempre fue un mal argumento, y ARC necesita arreglar lo que sea que lo convirtió en un problema (probablemente ya se solucionó con una actualización del compilador).
Y de ninguna manera aceptaría esto como”dejar que la gente lo pruebe”cuando
-como se mencionó, solo use KCFLAGS=-O3 si quiere
–O3 tiene un *largo* historial de generar código peor que-O2
así que *no* tomaré este tipo de parches sin algunas explicaciones muy serias de por qué-O3 de repente vuelva a ser aceptable.
Es mejor que esas explicaciones sean más que”dejar que la gente intente”. Deben tener números de rendimiento reales detallados para una carga real, no una lógica inventada de”más grande es mejor”.
Linus
