C ++ vs Fortran para HPC

En mi programa de doctorado en ciencias computacionales, estamos trabajando casi exclusivamente en C ++ y Fortran. Parece que algunos profesores prefieren uno sobre el otro. Me pregunto cuál es 'mejor' o si uno es mejor que el otro en ciertas circunstancias.

Como a menudo, la elección depende de (1) el problema que está tratando de resolver, (2) las habilidades que tiene y (3) las personas con las que trabaja (a menos que sea un proyecto en solitario). Dejaré (3) a un lado por el momento porque depende de la situación individual de todos.

Dependencia del problema: Fortran sobresale en el procesamiento de matrices. Si su problema puede describirse en términos de estructuras de datos simples y en matrices particulares, Fortran está bien adaptado. Los programadores de Fortran terminan usando matrices incluso en casos no obvios (por ejemplo, para representar gráficos). C ++ es más adecuado para estructuras de datos complejas y altamente dinámicas.

Dependencia de habilidades: se necesita mucha más experiencia en programación para escribir buenos programas de C ++ que para escribir buenos programas de Fortran. Si comienza con poca experiencia en programación y solo tiene tanto tiempo para aprender ese aspecto de su trabajo, probablemente obtendrá un mejor retorno de la inversión aprendiendo Fortran que aprendiendo C ++. Suponiendo, por supuesto, que su problema es adecuado para Fortran.

Sin embargo, hay más en la programación que solo Fortran y C ++. Se lo recomendaría a cualquiera que entre en la ciencia computacional para comenzar con un lenguaje dinámico de alto nivel como Python. ¡Recuerde siempre que su tiempo es más valioso que el tiempo de CPU!

Creo que tanto C ++ como Fortran son lo suficientemente buenos y funcionan bien.

Sin embargo, creo que Fortran es mejor para la computación científica numérica , para algoritmos que se pueden expresar usando matrices y no necesitan otras estructuras de datos sofisticadas, por lo que en campos como diferencias / elementos finitos, solucionadores de PDE, cálculos de estructuras electrónicas. Fortran es un lenguaje de dominio específico. En particular, creo que es más fácil escribir programas rápidos en Fortran que en C ++, por un científico (no necesariamente un experto en informática).

C ++ es un lenguaje de propósito general, por lo que uno puede expresar cualquier algoritmo en él, y definitivamente es mejor para los algoritmos que no se pueden expresar usando matrices, desde el campo HPC probablemente algunos gráficos, generadores de malla, manipulación simbólica, etc.

También es posible escribir algoritmos de matriz en C ++, pero en mi experiencia, requiere mucho más conocimiento de informática y, en general, más trabajo (es decir, uno necesita crear o reutilizar clases para la manipulación de matriz, y manejar la gestión de memoria a mano o usando algunos biblioteca como Teuchos de Trilinos). Los no expertos tienden a escribir programas de Fortran bastante buenos, pero horribles programas de C ++ (hablando desde mi propia experiencia).

Descargo de responsabilidad: personalmente me gusta mucho Fortran y lo prefiero a C ++ para la computación numérica. He pasado más de 2 años programando en C ++ diariamente, y casi un año programando en Fortran moderno diariamente (en el área de elementos finitos). También uso mucho Python y Cython.

También estoy arrojando mis dos centavos en los últimos tiempos, pero acabo de ver este hilo y siento que, para la posteridad, hay algunos puntos que necesitan desesperadamente hacerse.

Tenga en cuenta a continuación que hablaré sobre C y no sobre C ++. ¿Por qué? Bueno, de lo contrario son manzanas y naranjas comparar un lenguaje orientado a objetos dinámicamente desarrollado con algo tan estático como Fortran. Sí, algunas implementaciones modernas de los últimos estándares de Fortran pueden hacer más que eso, pero muy pocas personas los usan, por lo que cuando hablamos de Fortran, pensamos en un lenguaje simple, estático e imperativo. Ahí es donde también está C, así que reemplazaré C con C ++ para lo siguiente.

En primer lugar, cualquier discusión sobre Fortran / C con mejores compiladores es discutible. Los compiladores dedicados de C / Fortran son cosa del pasado. Tanto gcc / gfortran como icc / ifc son solo front-end diferentes para el mismo back-end, es decir, su programa se transformará en una descripción abstracta por el front-end y luego será optimizado y ensamblado por el back-end. Si escribe, semánticamente, el mismo código en Fortran o en C, el compilador, en ambos casos, producirá el mismo ensamblaje que se ejecutará igual de rápido.

Esto ahora lleva a mi segundo punto: ¿por qué todavía vemos diferencias? El problema es que la mayoría de las comparaciones son hechas por programadores de Fortran que intentan algo en C o viceversa. ¿Alguna vez notaste cómo la mayoría de los autores o poetas prefieren escribir en sus idiomas nativos? ¿Te gustaría escribir poesía en un idioma en el que no te sientas completamente seguro o en casa? Por supuesto que no ... yo mismo considero que C es mi lenguaje de programación "nativo". Sin embargo, también pasé tres años trabajando en un grupo que usaba solo Fortran, en el que había alcanzado un cierto nivel de fluidez. Sin embargo, nunca escribiría nada por mi cuenta en Fortran ya que me siento más cómodo con C y, como consecuencia, el código resultante será mejor , independientemente de lo que defina como.

Entonces, la principal diferencia está en el programador, no en el lenguaje. ¿Entonces no hay diferencias? Bueno, no del todo. Aquí están algunos ejemplos:

• SIMD: Ya sea SSE, SSE3 o AltiVec, si desea usarlos en Fortran, es mejor que espere y ore para que el compilador adivine exactamente lo que quiere y lo haga. Buena suerte. En C, generalmente tiene funciones intrínsecas para cada arquitectura o, más recientemente, tipos de vectores SIMD generales en gcc . La mayoría de los compiladores de Fortran solo usarán instrucciones SIMD para desenrollar bucles, pero si tiene un núcleo que funciona en vectores cortos de datos de una manera no obvia, el compilador probablemente no lo verá.

• Diferentes arquitecturas de hardware: toda la arquitectura CUDA está construida alrededor de los núcleos en C. Sí, el Grupo Portland ahora también tiene un compilador fortran compatible con CUDA , pero es comercial, y lo más importante, no es de NVIDIA. Lo mismo ocurre con OpenCL, para el cual lo mejor que pude encontrar es un proyecto reciente que solo admite algunas llamadas básicas.

• Programación en paralelo: Sí, tanto MPI como OpenMP funcionan bien tanto con C como con Fortran. Sin embargo, si desea un control real de sus subprocesos, es decir, si tiene un cálculo de memoria compartida totalmente dinámico, estará fuera de combate con Fortran. En C tienes los hilos estándar que, aunque no son cálidos y difusos, aún te ayudarán a superar la tormenta. En general, la mayoría de los cálculos que dependen del acceso al sistema operativo, por ejemplo, subprocesos, procesos, sistema de archivos, etc., se sirven mejor con C. Oh, y no intentes hacer tu propia red con Fortran.

• Facilidad de uso: Fortran está más cerca de Matlab que C. Una vez que haya superado todas las diferentes palabras clave y cómo declarar variables, el resto del código se parece a Matlab, lo que lo hace más accesible para los usuarios con experiencia de programación limitada.

• Interoperabilidad: cuando crea una estructura en C, el diseño de los datos reales es directo y determinista. En Fortran, si utiliza matrices de punteros o datos estructurados, el diseño real de los datos depende en gran medida del compilador, no es sencillo y, por lo general, no está documentado. Puede llamar a C desde Fortran y viceversa, pero no empiece a pensar que puede ser tan fácil pasar algo más que una matriz estática de uno a otro y viceversa.

Todo esto es algo geek, de bajo nivel, pero estamos hablando de computación de alto rendimiento, ¿verdad? Si no está interesado en cómo explotar mejor los paradigmas de hardware subyacentes, es decir, implementar y / o desarrollar algoritmos que sean mejores para memoria compartida / distribuida, subprocesos, vectorización SIMD, GPU que usan SIMT, etc., entonces está solo haciendo matemáticas en una computadora.

Esto se ha vuelto mucho más largo de lo que entendí, así que aquí hay un resumen: un conjunto de mensajes para llevar a casa:

• Usted tendrá que escribir el mejor código que puede en el lenguaje que usted sabe mejor.
• No hay diferencia en la calidad del código producido por dos compiladores que usan el mismo back-end: somos nosotros quienes escribimos el código incorrecto en un idioma u otro.
• A pesar de sentirse más de bajo nivel, Fortran es una abstracción de alto nivel y no le permitirá acceder a ciertas funciones de hardware / sistema operativo directamente, por ejemplo, SIMD, hilos, redes, etc.

De mis 15 años de pensar en software científico: si su código se ejecuta un 25% más rápido porque lo escribe en Fortran, pero le toma 4 veces más tiempo escribirlo (sin STL, dificultad para implementar estructuras de datos complejas, etc.), entonces Fortran solo gana si pasas una fracción significativa de tu día haciendo girar los pulgares y esperando que terminen tus cálculos. Dado que para casi todos nosotros lo más valioso es nuestro propio tiempo, la conclusión es la siguiente: utilice el lenguaje que le permita desarrollar, depurar y probar su código lo más rápido posible, ignorando que puede ser más lento de lo posible si Lo escribiste en Fortran.

Mi enfoque ha sido utilizar C ++ para todo excepto los núcleos computacionales, que generalmente se escriben mejor en ensamblador; esto le compra todo el rendimiento del enfoque tradicional de HPC pero le permite simplificar la interfaz, por ejemplo, sobrecargando núcleos computacionales como SGEMM / DGEMM / CGEMM / ZGEMM en una sola rutina, dice Gemm. Claramente, el nivel de abstracción puede elevarse mucho más evitando punteros sin procesar y cambiando a clases opacas, pero es un buen primer paso.

Creo que el mayor inconveniente de C ++ es abrumadoramente el aumento en el tiempo de compilación, pero, en mi experiencia, los ahorros en tiempo de desarrollo lo compensan con creces. Otra desventaja es que los compiladores de C ++ del vendedor tienden a tener más errores que los compiladores de C y Fortran. En el último año, creo que me he encontrado con casi diez errores en los compiladores de C ++.

Dicho todo esto, creo que deshacer los paquetes científicos escritos en lenguajes de bajo nivel (y Fortran) es la renuencia a exponer interfaces convenientes para estructuras de datos sofisticadas: la mayoría de las personas están satisfechas con la interfaz Fortran BLAS, ya que solo requiere punteros y dimensiones iniciales para describir matrices, pero pocas personas argumentarían que la interfaz habitual de solución dispersa directa Fortran de 40 enteros es algo conveniente (cf. UHM, SuperLU, PETSc y Trilinos).

En resumen, defiendo el uso de ensamblaje para núcleos computacionales de bajo nivel, pero lenguajes de nivel superior para todo lo demás, especialmente cuando se opera en estructuras de datos no triviales.

$y := \alpha x + y$

Como soy nuevo aquí, estaba revisando viejas preguntas y encontré esta. ¡Ojalá no sea tabú responder a las viejas!

Como nadie más ha mencionado esto, pensé que lo haría. Fortran 2003 es casi totalmente compatible con la mayoría de los principales compiladores (intel, ibm, cray, NAG, PCG), incluso gcc con la versión 4.7 (próximamente). Fortran 2003 (y 2008) es un lenguaje orientado a objetos, aunque un poco más detallado que C ++. Una de las cosas que creo que es bueno de Fortran es el hecho de que el comité estándar considera que la informática científica es su audiencia principal (agradezco a Damian Rouson por haberme señalado esto el otro día).

Traigo todo esto no para que los programadores de C ++ se conviertan en programadores de Fortran, sino para que las personas de Fortran sepan que ahora tienen más opciones además de cambiar a C ++ o emular conceptos orientados a objetos en Fortran 90/95.

Una advertencia que agregaré es que hay un costo por estar a la vanguardia de lo que se implementa en los compiladores. Si emprende un proyecto importante en Fortran 2003 en este momento, se encontrará con errores y continuamente necesitará actualizar su compilador (especialmente si usa gcc), ¡aunque esto ha mejorado significativamente en los últimos meses!

El problema con C ++ es que tiene numerosas posibilidades de arruinar el rendimiento, por ejemplo, utilizando ciegamente STL, excepciones, clases (sobrecarga virtual más problemas de alineación), sobrecarga del operador (nuevas / eliminaciones redundantes) o plantillas (compilación interminable y errores crípticos parece benigno, pero puedes perder horas de esta manera).

Sin embargo, cuanto más obtenga un mejor acceso a las bibliotecas generales y posiblemente una mayor visibilidad de su código (aunque esto depende en gran medida del campo, y todavía tiene C puro). Y aún puede compensar la falta de flexibilidad de Fortran envolviendo su código en un lenguaje de script como R, Lush, Matlab / Scilab o incluso Python, Ruby o Lua.

Tres hechos:

• Matrices n-dimensionales de estilo F77 en C: no hay problema con CnD (un complemento descarado, sin duda)

• El sistema de módulos de F90 está mal diseñado y es hostil para crear entornos. (El nombre de un módulo no tiene que coincidir con su nombre de archivo, por ejemplo)

• Fortran no admite la refactorización bien. Sacar un poco de funcionalidad de una función requiere que toque cuatro lugares: código real, declaraciones de variables, declaraciones de argumentos y lista de argumentos. C pasa con dos lugares para tocar. Esto agrava el efecto de la incapacidad de administrar bien los datos (descritos a continuación): dado que la modularidad a pequeña escala es tan dolorosa, casi todos escriben subrutinas gigantes.

Una impresión personal:

• Fortran no funciona bien para administrar datos. Intente devolver un puntero a una estructura de datos opaca para el usuario en F77 o F90. ( transfer()aquí vamos)

Fortran está optimizado para cálculos de matriz / matriz y es un trabajo minucioso para trabajar con cualquier tipo de análisis de texto. C y C ++ pueden no coincidir con Fortran en computación numérica (está cerca), pero me resulta mucho más fácil procesar texto y organizar datos (es decir, estructuras de datos personalizadas) con C / C ++.

Como otros han mencionado, no cuente los lenguajes dinámicos interpretados (Python et al). Es posible que no ofrezcan la velocidad de fusión de Fortan por adelantado, pero le permiten concentrarse más en resolver su problema computacional que todos los detalles de la implementación. A menudo puede implementar una solución en Python, y si el rendimiento es inaceptable, realice algunos perfiles, identifique las áreas problemáticas y optimice ese código usando Cython o vuelva a implementar todo el programa en un lenguaje compilado. Una vez que se ha desarrollado la lógica de resolución de problemas, el resto es solo implementación y, con una buena comprensión de los fundamentos de la informática, debe ser sencillo de representar en cualquier variedad de lenguajes de programación.

Actualmente estoy trabajando en uno de los laboratorios nacionales. La mayoría de las personas que me rodean son ingenieros mecánicos. Al chatear con algunas de las personas de los grupos de HPC, están haciendo principalmente Linux y C ++. El grupo en el que estoy actualmente usa principalmente aplicaciones de escritorio y usamos Windows y en orden descendente: C #, FORTRAN, Python, VBA y VB (6, no .NET). Algunos de los motores de simulación que utilizamos fueron escritos en otros laboratorios nacionales en FORTRAN.

Perdón por desenterrar un hilo antiguo, pero parece que incluso en 2015, Fortran se está utilizando mucho.

Acabo de encontrar esta lista ( enlace alternativo ) que básicamente es una lista de 13 códigos aprobados por la instalación OCLF del DOE para ejecutarse en la máquina 300-petaFLOPS Summit que estará disponible para los investigadores en 2018. Intenté encontrar el idioma principal utilizado para el código (basado en una búsqueda rápida en Google) y esto es lo que encontré:

XGC Fortran

SPECFEM Fortran

ACME Fortran (Bunch of climate codes)

DIRAC Fortran (Mostly)

FLASH Fortran

GTC Fortran

HACC C/C++

LS-DALTON Fortran (some C)

NAMD C/C++

NUCCOR Fortran

NWCHEM Fortran

QMCPACK C++

RAPTOR Fortran

Entonces, de 13 códigos, al menos 10 (según mi búsqueda rápida) parecen estar escritos en Fortran. No está mal para un idioma de 50 años.

NOTA: Soy consciente de que las comparaciones de lenguaje son inútiles, pero dada la cantidad de personas (especialmente los usuarios de C ++) que hablan mal de Fortran, pensé que valdría la pena mencionarlo.

Lo que Jack P. creo que intenta decir es que debes mezclar y combinar. Una buena pieza de software está cuidadosamente en capas. Las diferentes capas pueden mapearse de forma más natural o eficiente a diferentes idiomas. Debe elegir el idioma más apropiado para cada capa. También debe comprender cómo pueden interactuar los idiomas, lo que puede afectar el idioma que elija para cada capa.

Una mejor pregunta es qué ejemplos de software excelentemente diseñados existen que valga la pena estudiar para aprender cómo diseñar software en capas.