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)? .
Respuestas:
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
(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 ...
fuente
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.
fuente
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 .
fuente
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.
fuente
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.
fuente
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.
fuente
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.
fuente