¿Cómo se puede modernizar una gran base de código de procesamiento de números basada en Fortran?

21

Un amigo en la academia me pidió consejo (soy un desarrollador de aplicaciones empresariales C #).

Tiene una base de código heredada que escribió en Fortran en el campo de la imagen médica. Realiza una gran cantidad de números usando vectores. Él usa un clúster (núcleos de 30ish) y ahora se ha dirigido hacia una única estación de trabajo con GPUS de 500ish.

Sin embargo, ¿a dónde ir después con la base de código?

  • Otras personas pueden mantenerlo durante el próximo ciclo de 10 años.
  • Acelera al ajustar el software
  • Puede ejecutarse en diferentes infraestructuras sin recompilar

Después de una investigación mía (esta es un área súper interesante), algunas opciones son:

  • Use Python y CUDA de Nvidia
  • Reescribe en un lenguaje funcional. Por ejemplo, F # o Haskell
  • Vaya basado en la nube y use algo como Hadoop y Java
  • Aprender C

¿Cuál ha sido tu experiencia con esto? ¿Qué debería mirar mi amigo para modernizar su base de código?

ACTUALIZACIÓN: Gracias @ Mark y todos los que han respondido. Las razones por las que mi amigo hace esta pregunta es que es un momento perfecto en el ciclo de vida de los proyectos para hacer una revisión. Poner al día a los asistentes de investigación en Fortran lleva tiempo (¡me gusta C #, y especialmente las herramientas y no puedo imaginar volver a los idiomas más antiguos!)

Me gustó la sugerencia de mantener el número puro en Fortran, pero envolviéndolo en algo más nuevo. Quizás Python ya que parece estar obteniendo una fortaleza en la academia como un lenguaje de programación de propósito general que es bastante fácil de aprender.

Vea Medical Imaging y un tipo que ha escrito un contenedor Fortran para CUDA. ¿Puedo publicar legalmente mis contenedores Fortran 90 en la biblioteca CUFFT de Nvidias (del SDK de CUDA)? .

Dave Mateer
fuente
Añadiría OpenCL a la lista.
Jerry Coffin
3
Hola Dave, hay un cierto tipo de "¿Qué idioma debo aprender a continuación?" pregunta que no permitimos aquí, así que hice revisiones menores para asegurarme de que la gente no confunda esta pregunta con eso. Pero, ¿puede ampliar su pregunta para explicar por qué las opciones que ha descubierto hasta ahora no encajan bien para que pueda orientar las respuestas para proporcionar un mejor ajuste?
¿Qué quiere decir específicamente en "Puede ejecutarse en diferentes infraestructuras sin recompilar"?
Torre
Hola @Idigas: no estoy muy seguro de los detalles. Pero, esencialmente, la historia decía que al llevar la base de código a otros clústeres / máquinas se estaba convirtiendo en una pesadilla obtener todas las versiones correctas de las bibliotecas para compilar juntas. Creo que la base de código fue tomada de F77 a F90 o lo que sea. Básicamente estoy tratando de ayudarlo a hablar con las personas adecuadas para tomar una decisión inteligente sobre si cambiar las arquitecturas / idiomas. Vengo de un entorno en el que a los clientes no les gusta un día de tiempo adicional de codificación, por lo que cualquier cosa que pueda hacer para ayudarme a escribir el mejor código posible lo más rápido es ideal :-)
Dave Mateer
@DaveMateer - Mira mi respuesta (no encaja en este cuadro aquí). Me voy a dormir ahora, así que las respuestas futuras pueden ser un poco lentas :)
Rook

Respuestas:

24

Las demandas que ha puesto realmente ponen a Fortran en la parte superior de la lista, para problemas como este:

a) procesamiento de números
b) paralelable
c) era y sigue siendo el lenguaje de facto que se enseña fuera de los estudios de cs (para ingenieros que no son programadores profesionales).
d) tiene un increíble (!) respaldo de la industria, en cuanto a la cantidad de compiladores de grado de la industria, sin que ninguno de los proveedores muestre las menores señales de abandonar esa sucursal. No hace mucho, uno de los representantes de Intel reveló que las ventas de sus productos Fortran son más altas que cualquier otra en sus herramientas de desarrollo.

También es un lenguaje increíblemente fácil de aprender. No estoy de acuerdo en que lleve tiempo poner al día a los asistentes de investigación. Mi primer libro de texto no tenía más que, oh no sé, 30 (?) Páginas de texto impreso escaso. Es un lenguaje en el que después de aprender 10 palabras clave, uno puede escribir programas de tamaño mediano. Me atrevería a decir que esas 30 páginas escritas en texto predeterminado de Word serían un "manual de Fortran" más completo para la mayoría de los usuarios.

Si está interesado en CUDA, puede consultar el compilador de Portland Group , que lo admite . No estoy familiarizado con los detalles más finos, pero la gente generalmente habla de ello con elogios.

Además de eso, para los programas en paralelo, tiene disponibles OpenMP, MPI y ahora los próximos (y muy esperados) arreglos, que el compilador de Intel ha implementado recientemente . Para no desperdiciar palabras, Fortran tiene una gama muy fina de "bibliotecas" para paralelizar programas.

Las bibliotecas numéricas estándar de la industria se desarrollan principalmente, otros idiomas siguen más o menos en la cartera de funciones / rutinas.

Dicho todo esto, sin embargo (depende de cuándo se escribió originalmente) recomendaría si es, digamos, un código F77 o anterior, reescribiéndolo parcialmente a través del tiempo a dialectos más nuevos, al menos F90, si es posible con las funciones F2003. Recientemente se publicó un documento / tesis sobre ese tema (archivo PDF de tamaño medio más adelante). Eso no solo puede, si se hace correctamente, garantizar la portabilidad en múltiples plataformas, sino que también facilitará el mantenimiento futuro.

ps En cuanto al "mantenimiento futuro", solo una anécdota que a veces me gusta mencionar. Mientras escribía mi tesis, reutilicé un código de mi mentor, escrito hace 35 años desde el momento de la escritura. Se compiló con un solo error; falta una declaración al final, debido al error de copiar y pegar :)


@DaveMateer (responder al comentario) : voy a hacer un comentario a continuación, que puede ser un poco descortés, pero no lo tome de la manera incorrecta, ya que tiene buenas intenciones.

Me parece que estás abordando este "problema" de manera incorrecta. Lo que quiero decir en unos pocos puntos breves (porque es muy tarde aquí, y mi capacidad para inventar oraciones legibles (y mucho menos comprensibles) me deja después de las 10 p.m.)

a) mencionó que está tratando de minimizar el tiempo de codificación adicional, pero está considerando una reescritura de un lenguaje especializado en computación numérica a uno de una colorida selección de idiomas , si perdona mi expresión

  • algunos de los cuales no tienen soporte para matrices multidimensionales, entre otras cosas
  • la mayoría de ellos no son aptos para trabajos numéricos pesados ​​(de las capacidades de procesamiento paralelo de Haskell y Hadoop, lo admito, no sé nada ... pero nunca los he escuchado mencionar en esos círculos)
  • posiblemente ha sido probado, pero nunca he oído hablar de una reescritura de Fortran, un lenguaje para problemas discretos, a un lenguaje funcional
  • recientemente ha habido una discusión sobre comp.lang.fortran (intente buscar en los grupos de Google) sobre los aspectos de la informática científica "en la nube"
    (no quisiera desmotivarlo, pero para ser justos, nadie era realmente seguro de lo que ese término representa, menos solo tenía un ejemplo de una aplicación exitosa. La mayoría de la gente estuvo de acuerdo en que existe el potencial, pero hasta ahora están contentos de cómo funcionan las cosas por ahora). Muchos problemas tampoco son adecuados para ese tipo de paralelización.

b) ¿cuáles serían los costos de tal reescritura? personas / horas.

c) -correcciones correctas de las bibliotecas para compilar ...- es un problema en cualquier idioma, que no se puede evitar, lo mire como lo mire.

d) He oído hablar de Python (un lenguaje agradable realmente) utilizado en aplicaciones paralelas en algunas ocasiones, pero su penetración en ese mercado todavía no parece estar aumentando, y su naturaleza siempre cambiante lo convierte en una muy mala elección para un proyecto a largo plazo (piense en la compatibilidad con versiones anteriores). A algunas personas les gusta mucho como lenguaje de "pegamento".

Ugh, si pienso en algo más, lo agregaré mañana. Tengo que dormir un poco ...

Torre
fuente
@Idigas ... muy apreciado de nuevo. Totalmente de acuerdo en que una vez que algo funciona, eso significa mucho. Nuestra industria está plagada de reescrituras totales que van terriblemente mal (¡Netscape!).
Dave Mateer
1
Idigas tiene la idea correcta aquí. Tiene una base de código de trabajo que ha estado funcionando durante años, y la transcripción generará errores. Además, Fortran es un lenguaje simple de aprender, puede ser feo pero está hecho de conceptos claros. Mantenga las dependencias en / a otro código bajo control y tal vez escriba una buena interfaz de estilo C para Fortran y encontrará que el código es notablemente a prueba de futuro (estilo C, ya que casi cualquier otro idioma tiene un mecanismo para llamar código con una interfaz de estilo C).
anon
2
Tengo que estar de acuerdo. Si comprende las matemáticas detrás de lo que está haciendo (y la mayoría de los ingenieros lo hacen), implementarlo en FORTRAN no es una curva de aprendizaje tan empinada. Una vez que lo haya construido, los requisitos rara vez cambiarán, como pueden ocurrir en las aplicaciones comerciales o sociales.
JeffO
Wow, no sabía que había tanto amor por FORTRAN. Tuve que desarrollarme en F77 durante 5 años y no puedo soportarlo.
dodgy_coder
2
@dodgy_coder. Es bueno saber que desarrollaste en Fortran + .NET en los años noventa. La primera versión beta de .NET salió en 2000.
10

Dudo que Fortran muera alguna vez: tiene un legado de software y bibliotecas tan grande escrito que la gente todavía está trabajando en él, solo estabilizando esta situación. Además, sigue siendo un lenguaje muy bueno si no desea hacer nada más que la combinación de números: la sintaxis es muy elegante y lógica, además el compilador puede adivinar fácilmente lo que está sucediendo. Por lo tanto, se garantiza que cualquier nueva tecnología de acelerador de hardware admitirá C, Fortran y algún tipo de OpenCL (cuando finalmente convergería en algo sólido).

Entonces, diría que debe separar claramente la parte numérica, dejarla en Fortran, hacer un enlace claro y escribir el resto en lo que quiera.

mbq
fuente
Sin mencionar que los nuevos proyectos en Fortran también se inician hoy en día.
Torre
Sí, Fortran no es COBOL, no solo es compatible solo porque eso es lo que la gente aprendió hace 30 años (aunque IMO es parte de eso). Sin embargo, la reducción de números no es mi fuerte, así que si hay algo mejor, ciertamente no lo sé.
Ben Brocka
1
El lenguaje fortran todavía tiene una ventaja de diez años en la reducción de números y las optimizaciones asociadas. No va a morir en el corto plazo.
Martin York
1
El artículo apareció en un reciente "Comunicaciones de la ACM" sobre Fortran y cómo sigue y sigue con las modernizaciones sucesivas. Mantener (al menos la parte del número) del código en Fortran probablemente sería un buen movimiento. También ayuda a evitar el síndrome de Netscape (reescribir = nuevos errores = gran tiempo de ciclo = enojar a todos los involucrados).
rapid_now
1
¿Realmente quieres que alguien que no esté interesado en Fortran toque tu código de número? Un gran problema es asegurarse de que el resultado sigue siendo preciso después de una reescritura.
Peter Smith
4

Python está ganando mucha tracción en la comunidad de informática científica (para una vista algo desactualizada, ver el volumen 9 número 3 de CiSE ). Creo que un híbrido Python / Fortran es una excelente manera de hacerlo. Para aprovechar todas esas GPU, puede usar PyCUDA o PyOpenCL .

Soy un matemático que analiza y escribe solucionadores numéricos para ecuaciones diferenciales parciales. Hace poco estuve en una situación similar a la de tu amigo; El código Fortran 77 en cuestión es el conocido software Clawpack . Reescribimos el código de nivel superior (todas las partes que no necesitan ser rápidas) en Python y usamos f2py para ajustar automáticamente las partes de bajo nivel.

El resultado realmente poderoso de esto es que pudimos conectar casi trivialmente el código híbrido Python / Fortran (denominado PyClaw ) con la biblioteca paralela PETSc, creando por primera vez una versión paralela escalable de Clawpack que funciona bien en núcleos de 65K. Todo el código paralelo que tuvimos que escribir está contenido en menos de 300 líneas de Python . Ahora estamos resolviendo problemas que posiblemente no podrían haberse abordado solo con el código heredado. Igual de importante, ahora es mucho más fácil para los nuevos usuarios recoger el código, ya que Python es un lenguaje tan amigable y casi todo se puede modificar en tiempo de ejecución en lugar de en tiempo de compilación.

Si desea ver más detalles de nuestro enfoque y resultados, tenemos un documento sobre el arXiv .

Disculpas por la autopublicidad, pero parecía que mi experiencia personal sería relevante aquí. Si desea escuchar muchas más ideas, puede publicar esto también en el nuevo http://scicomp.stackexchange.com .

David Ketcheson
fuente
1

Actualmente estoy en una situación muy similar a la de tu amigo. También estoy desesperado por "modernizar" mi código heredado KLOC Fortran-77 de 40 años. Y a pesar de que Fortran todavía se considera el rey en las aplicaciones de cálculo de números, me gustaría decir que no todo está perdido. (Lo que sigue es rant-ish, así que tengan paciencia conmigo).

El hecho de que Fortran sea el mejor lenguaje para el código numérico no significa que tengamos que llevar este enorme equipaje de un código complicado y desordenado con nosotros todo el tiempo (Sí, un código de Fortran seguramente será desordenado, especialmente Fortran-77 que es un lenguaje que literalmente no tiene en cuenta la ingeniería de software, cuando cruza ciertos KLOC). Aquellos que abogan por Fortran para descifrar números olvidan la observación general de que cuando se realiza un análisis de rendimiento de dichos códigos, solo el 5% o el 10% del código es intensivo en rendimiento y para el 90% + Fortran restante es una sobrecarga inútil, solo para hacer de tu vida como "ingeniero de software" un infierno.

Cuando se muda a Fortran-90 desde Fortran-77, está esencialmente dispuesto a intercambiar el rendimiento con las características del lenguaje hasta cierto punto. Fortran es un poderoso generador de números principalmente debido a Fortran-77. Se podría decir que Fortran-90 es igual de rápido, pero el tipo de problemas de optimización con los que tuvieron que lidiar los escritores de compiladores al agregar las funciones de Fortran-90/2003 y mantener el rendimiento de Fortran-77 no son muy diferentes de los problemas que los escritores de compiladores de C tuvieron que tratar with (y como resultado, C también se considera rápido, sin mencionar que C también permite el montaje en línea). Entonces, ¿por qué no comenzar a agregar código C poco a poco (en lugar de Fortran-90) en un código Fortran-77. Mi código ya tiene piezas en C y piezas en Fortran-77 y funciona muy bien sujeto a algunos problemas como pasar cadenas, indexación cero / indexación única, etc. Pero la ventaja que obtengo de C,

Yo iría un paso más allá. Incluso C (y definitivamente Fortran-90/95/2003) tiene un nivel demasiado bajo si desea una buena interfaz "humana" para un código de números crujientes. Estoy pensando en pasar a un Python-Fortran-77 o un híbrido Python-C. Un código en el que el 90% del código es Python (incluidos Numpy, Scipy, plotability y toda esa dulzura) y solo el rendimiento intensivo del 5% -10% permanece como código Fortran-77 o C.

Yudle Joza
fuente
1
"un código de Fortran está destinado a ser desordenado". No. Un codificador desordenado escribirá código desordenado en cualquier idioma, y ​​lo contrario es cierto. Kernighan y Plauger han mostrado cómo escribir Fortran limpio hace años .
0

Actualmente estoy en el proceso de actualizar una antigua base de código FORTRAN95 para usar en entornos industriales modernos, ya que la versión anterior solo se ejecutará en máquinas Windows 2000 a más tardar. La propia base de código FORTRAN realiza una gran cantidad de cálculos numéricos relacionados con las simulaciones de riego.

Entonces, lo que estoy haciendo es en lugar de volver a escribir FORTRAN en un lenguaje más moderno, simplemente estoy usando un compilador comercial llamado Silverfrost FTN95 para compilar la base de código FORTRAN en una biblioteca .Net 4.0 que estoy usando como back-end de una aplicación WPF . De esta manera, no corro el riesgo de introducir errores conocidos en el código de simulación y lo estoy modernizando moviendo la base de código al marco .Net 4.0 para que se ejecute en entornos más modernos.

Pero dependiendo de qué tan grande sea su simulación, es posible que desee simplemente volver a escribir todo en un lenguaje más moderno como C #, estoy planeando hacerlo una vez que tenga una versión en ejecución de la simulación para comparar la salida.

Espero que mi experiencia ayude, gracias, Alex.

Alex Hope O'Connor
fuente
0

Fui líder de desarrollo en un proyecto de 2001-2003 que portó una aplicación de Windows 100KLOC de FORTRAN a C #. Era una aplicación de cálculo numérico que tenía sus propios enlaces GUI personalizados a las bibliotecas Win32. El puerto a C # y WinForms simplificó la administración del código y les dio a todos un entorno de desarrollo más rico en Visual Studio. Hubo un poco de resistencia temprana (especialmente en términos de formato de declaraciones), pero al final definitivamente valió la pena.

En mi opinión, tiene sentido morder la bala y deshacerse de la cantidad máxima de código FORTRAN posible. La velocidad nunca fue un problema: las pruebas iniciales que ejecutan el código en C # en comparación con FORTRAN encontraron que la diferencia de rendimiento es insignificante, a pesar de que C # ejecuta el código administrado. Sin embargo, sus necesidades con los vectores pueden ser un poco diferentes, y tener una cantidad minoritaria de código FORTRAN sobrante también sería aceptable.

Otra razón para hacerlo es, por supuesto, la disponibilidad a largo plazo de personas con experiencia en FORTRAN que pueden mantener su código en comparación con los desarrolladores de C #. Además, ayuda a la moral del equipo a trabajar en un lenguaje moderno y bien soportado.

dodgy_coder
fuente
0

Me han dicho que en muchos contextos, MATLAB está reemplazando a FORTRAN para la aplicación de computación científica. No solo es moderno y de alto nivel, también es bastante rápido en lo que hace. Muchos desarrolladores que trabajan en software de imágenes médicas ya usan MATLAB, por lo que tiene varias bibliotecas dedicadas a la imaginación médica. Esto significa que encontrará herramientas y soporte experto en dominios si utiliza MATLAB.

Oleksi
fuente