C ++ vs Fortran para HPC

56

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.

drjrm3
fuente
12
En mi opinión, una combinación de un lenguaje de alto y bajo nivel es mejor que usarlo exclusivamente. Por ejemplo, uso Python + C ++.
Faheem Mitha
2
Las respuestas a esta pregunta serán casi puramente subjetivas y, por lo tanto, no estoy seguro de que esta pregunta sea apropiada.
Jeff

Respuestas:

62

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!

Khinsen
fuente
17
"¡Recuerde siempre que su tiempo es más valioso que el tiempo de CPU!" Como alguien que trabaja en HPC, no estoy de acuerdo con esa parte; todo lo demás es perfecto.
Levi Morrison
19
"¡Recuerde siempre que su tiempo es más valioso que el tiempo de CPU!" Como alguien que trabaja en investigación científica, no podría estar más de acuerdo con esa parte.
decreta el
3
"¡Recuerde siempre que su tiempo es más valioso que el tiempo de CPU!" - Me gustaría agregar mis 2 centavos: usar varios cientos de nodos, cada uno con más de 10 núcleos para ejecutar algún programa durante varias semanas, puede interpretarse como un desperdicio horrible del recurso más preciado, si un par de semanas más pueden producir un código que se ejecuta en solo un par de días. Esos grupos de HPC son un recurso común raro y costoso.
Dani_l
"¡Recuerde siempre que su tiempo es más valioso que el tiempo de CPU!", Codifique durante una semana pero ejecute durante un mes, ¡esto es bastante habitual, señor!
fronthem
66
"¡Recuerde siempre que su tiempo es más valioso que el tiempo de CPU!", ¡Prefiero codificar durante un mes y ejecutarlo en una semana! - Se puede hacer más una vez que se escribe el código y otros encontrarán el código que usted escribe también más útil.
Charles
37

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.

Ondřej Čertík
fuente
1
Uno para la primera respuesta es equilibrado. Creo que C ++ y Fortran no son las únicas posibilidades en el HPC contemporáneo. Creo que es bueno saber la fuerza y ​​los puntos débiles cuando decides por Fortran, C ++ o Python (o lo que quieras). He visto 20,000 líneas de Fortran en un solo archivo, cultivado orgánicamente durante algunas décadas. Yo personalmente no usaría para otra cosa que no sea la informática de matriz pesada aislada. Ni siquiera para nada relacionado con la salida. Hasta ahora para un comentario sesgado.
shuhalo
66
No podría estar más en desacuerdo con esta respuesta. Nuestro código de elementos finitos no habría sido posible escribir en Fortran. De hecho, comenzó hace 15 años como una mezcla de C simple y Fortran (este último para las partes numéricamente intensivas del método), y gradualmente se movió a C puro y luego a C ++ en el transcurso de varios años. El código se hizo consistentemente más corto, más rápido y más fácil de entender, y fue más capaz después de cada iteración. Estoy de acuerdo con otros que señalan que C ++ te da mucha cuerda para dispararte. Elija el idioma con el que se sienta más cómodo.
Bill Barth
66
Bill, ¿usaste Fortran moderno (90 y adiciones posteriores?). Esto es muy importante (debería haber sido más explícito en mi respuesta sobre esto). Por supuesto, "20,000 líneas de Fortran", o f77, generalmente no es mejor que C ++ bien escrito.
Ondřej Čertík
1
@ OndřejČertík: Creo que si crees que los programas modernos de elementos finitos usan estructuras de datos "simples", entonces no has mirado ninguno de ellos recientemente. Intente implementar elementos adaptativos finitos, métodos hp o multirredes en mallas no estructuradas utilizando estructuras de datos simples. Bill es acertado y creo que puedo hablar por él al decir que usar "Fortran moderno" no habría hecho más que una pequeña diferencia.
Wolfgang Bangerth
66
@WolfgangBangerth, vea por ejemplo Phaml ( math.nist.gov/phaml ) para una implementación de Fortran de casi todo lo que mencionó.
Ondřej Čertík
31

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.
Pedro
fuente
55
Buena respuesta Sin embargo, no creo que tu comentario final sea necesariamente cierto. Yo también soy programador en C, pero tienes acceso a cosas de bajo nivel en Fortran a través de buenas prácticas de programación. La forma ideal de utilizar cosas como operaciones SIMD es escribir código que lo sugiera fuertemente (por ejemplo, bloquear bucles) y dejar que el compilador lo haga por usted. Para enhebrar, simplemente use openMP (pthreads también se puede usar con algo de trabajo adicional). Fortran tiene todas las cosas que usted menciona que no tiene, solo a un nivel que le importa a su usuario típico: numérico.
Reid.Atcheson
@ Reid.Atcheson: Bueno, si bloquea todo de manera que el compilador lo atrape, funcionará automáticamente tanto en C como en Fortran. El problema es, sin embargo, ¿hasta qué punto desea confiar en su compilador? ¿Y por qué quieres tener que confiar en él cuando sabes exactamente lo que quieres hacer? OpenMP hace subprocesos, sí, pero en bloque. Puede engañarlo para que obtenga diferentes grupos de subprocesos para hacer cosas diferentes, pero eso es simplemente mal uso de OpenMP. Pthreads para Fortran son solo envoltorios para las funciones de C. Sin embargo, estoy de acuerdo en que Fortran es más fácil si no te gustan los detalles.
Pedro
1
Seguro que no va a obtener una eficiencia máxima del 99% en total confiando en el compilador, pero puede acercarse fácilmente. Más allá de esto, debe usar intrínsecos o ASM en línea. Debe hacer concesiones en algún lugar para la eficiencia general del programador, por eso existen los lenguajes de programación en primer lugar. En la etapa en que realmente estás lo suficientemente loco como para entrar en detalles de intrínsecos o ASM (he estado varias veces), Fortran no es una muleta. De todos modos, sabría cómo vincular su código ensamblado optimizado a mano.
Reid.Atcheson
@ Reid.Atcheson: Bueno, yo diría que para las aplicaciones paralelas de HPC, puede terminar muy por debajo del 99% de eficiencia máxima ... Y los tipos de vectores gcc hacen que el uso de intrínsecos no sea un problema :)
Pedro
1
@Pedro, publicación brillante. Absolutamente brillante. Muchas gracias por postear. Lo encontré mientras hurgaba aleatoriamente en hilos interesantes.
Investigación
16

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.

Wolfgang Bangerth
fuente
13

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:=αx+y

Jack Poulson
fuente
2
¿Por qué no confiarías en un compilador C estándar con la optimización adecuada habilitada con el propósito de compilar pequeños núcleos? En ese nivel de tamaño y complejidad de código, la diferencia en lo que un compilador podría sacar de ella no está clara.
Peter Brune
1
He hablado con varias personas que me han dicho que, incluso con el uso restringido apropiado, su Fortran todavía era más rápido que su código C y / o C ++ para algunas operaciones como una transposición explícita de matrices. No digo que sea imposible hacer que el código C o C ++ sea tan rápido, sino que el compilador Fortran tiende a hacer un mejor trabajo.
Jack Poulson
Tengo la misma experiencia con la palabra clave "restringir" (mi código Fortran simple siempre fue un poco más rápido). Pero mi experiencia es limitada, y simplemente no tengo tiempo para invertir en comprender el ensamblaje generado por gcc. Así que simplemente uso Fortran, es simple y rápido.
Ondřej Čertík
@JackPoulson: El argumento del compilador es algo que escucho bastante de la comunidad de Fortran. Desafortunadamente, la mayoría de los compiladores, por ejemplo, gcc o ifc / icc, usan front-end de diferentes idiomas para el mismo back-end. La maquinaria que realiza la optimización y la generación de código es idéntica y, por lo tanto, las diferencias en los resultados se deben probablemente a diferencias en la familiaridad del programador con el lenguaje subyacente ...
Pedro
1
Solo para dar un poco de perspectiva sobre la afirmación a menudo repetida y raramente validada de que Fortran es más rápido en núcleos numéricos: Hace un tiempo, notamos que la multiplicación del vector matriz escaso en el paquete Epetra de Trilinos era 30% más lenta que la de trato.II. El primero fue escrito en Fortran 77 directo, el último en C directo sin el uso de 'restringir'. Ambos tenían alrededor de 10-15 líneas de código. Hoy, Trilinos usa el código extraído del acuerdo. II. Estoy seguro de que uno puede encontrar muchos casos en los que F77 es más rápido que C. El punto es que hoy en día no es universal.
Wolfgang Bangerth
8

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!

Jeremy Kozdon
fuente
7

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.

mbq
fuente
1
Generalmente es una mala idea aplicar técnicas de bajo nivel en lenguajes de alto nivel. Por ejemplo, el STL está diseñado para operar en un nivel muy abstracto. Hay que tener en cuenta para qué está diseñada la interfaz, usarla para esta tarea y luego salir del camino de los compiladores.
shuhalo
2
Creo que los puntos de mbq y Martin son injustos. Sí, hay formas de dispararse en el pie si intenta implementar un vector numérico para propósitos de álgebra lineal usando std :: list <double>. Pero ese es un argumento tonto: al menos C ++ tiene una clase de lista vinculada que puede usar, mientras que Fortran no. Es como decir: "Los automóviles conducen a una velocidad tan alta que podría chocar contra una pared y lesionarse; en su lugar, debería usar carruajes tirados por caballos". Es una idea tonta descartar un lenguaje de alto nivel que también admite cosas de bajo nivel (por ejemplo, C ++) por tener características de alto nivel.
Wolfgang Bangerth
@WolfgangBangerth No, ahora estás lastimando a Fortran, es tan "de bajo nivel" como las bacterias están "menos evolucionadas" que los humanos. Si desea una analogía de automóvil, debería ser más como "puede usar Jeep y Lexus para cruzar un camino pantanoso, pero usar el primero duele menos".
mbq
1
Agradezco su opinión, pero mantengo que Fortran no está tan evolucionado como C ++ :-)
Wolfgang Bangerth
7

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)
Andreas Klöckner
fuente
Hola andres CnD es interesante, no lo sabía. Ah, lo escribiste. :) (f90 también es compatible con segmentación, asignable para matrices y, lo más importante, sintaxis de matriz para multiplicación, suma, etc.) Utilizo CMake con Fortran y funciona muy bien con los módulos. ¿Qué es exactamente la "lista de argumentos"? No creo que use estos, por lo que solo se necesitan 3 lugares para modificar. En C, generalmente necesita modificar el código real, los parámetros y un archivo de encabezado, por lo que también tiene 3 lugares (definitivamente en C ++). Sí, transfer () no es súper agradable, pero generalmente no lo necesitas en la práctica.
Ondřej Čertík
3
Refactorizar el fortran moderno es trivial con IDEs adecuados, como Photran en eclipse.
2
"El nombre de un módulo no tiene que coincidir con su nombre de archivo, por ejemplo" Debe estar bromeando, puede tener muchos módulos en un archivo. Algunos de ellos abarcan solo un par de líneas. Son mucho más fáciles de crear si no tiene que crear un archivo para cada uno de ellos.
Vladimir F
1
Solo quería agregar a lo que @ user389 dijo que, si bien Photran es excelente y es el único IDE de Fortran que permite refactorizaciones, su analizador falla todo el tiempo. Por otro lado, no hay necesidad de comentar sobre el hecho de que Eclipse necesita mucha memoria.
astrojuanlu
5

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.

Daniel Standage
fuente
Eso es correcto. Para el análisis de texto también uso Python.
Ondřej Čertík
También puede implementar parte de una secuencia de comandos de Python en un lenguaje compilado por ejemplo, C ++ y engancharlo en, por ejemplo Boost Python, etc. trago.
Faheem Mitha
4

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.

Tangurena
fuente
4

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.

stali
fuente
3
No estoy de acuerdo, porque mi experiencia en los laboratorios nacionales ha sido, en todo caso, lo contrario. La mayoría de los nuevos proyectos que veo en Lawrence Livermore están escritos en C ++, y la mayoría de las bibliotecas de código abierto nuevas (o mantenidas activamente) de vanguardia en solucionadores de ODE, discretizaciones de FEM y bibliotecas de computación científica de propósito general parece estar en C o C ++. Fortran parece usarse principalmente en proyectos que usan bibliotecas existentes / heredadas; No veo muchos proyectos nuevos y grandes con Fortran, independientemente de lo que piense sobre el lenguaje.
Geoff Oxberry
Algunos códigos de teoría funcional de densidad también escritos en Fortran incluyen VASP y CASTEP , aunque como señala @GeoffOxberry, los nuevos proyectos tal vez tienden hacia C ++.
dr.blochwave
@blochwave Como puede leer en el enlace, los proyectos son para una nueva máquina (con aceleradores, etc.) que estará en línea en 2018. Por lo tanto, no es como si tomaran un código de 25 años y lo compilaran, con la esperanza de funcionar con buena calidad actuación. Estoy bastante seguro de que grandes partes de los códigos en la lista anterior se han reescrito o se han reescrito, como en el nuevo código. Varios códigos climáticos "nuevos" también se encuentran en Fortran y son utilizados por muchas agencias en varios países.
stali
0

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.

Robert van de Geijn
fuente