Come si può ammodernare una base di codice di grandi dimensioni basata su Fortran?


21

Un amico del mondo accademico mi ha chiesto consiglio (sono uno sviluppatore di applicazioni aziendali C #).

Ha una base di codice legacy che ha scritto a Fortran nel campo dell'imaging medico. Fa un'enorme quantità di scricchiolii numerici usando i vettori. Usa un cluster (30 core) e ora è passato a una singola workstation con GPUS 500ish.

Comunque dove andare dopo con la base di codice così:

  • Altre persone possono mantenerlo nel prossimo ciclo di 10 anni
  • Diventa più veloce nel modificare il software
  • Può funzionare su diverse infrastrutture senza ricompilare

Dopo alcune ricerche da me (questa è un'area super interessante) alcune opzioni sono:

  • Usa Python e CUDA di Nvidia
  • Riscrivi in ​​un linguaggio funzionale. Ad esempio, F # o Haskell
  • Passa al cloud e usa qualcosa come Hadoop e Java
  • Impara C.

Qual è stata la tua esperienza con questo? Cosa dovrebbe guardare il mio amico per modernizzare la sua base di codice?

AGGIORNAMENTO: Grazie @Mark e tutti coloro che hanno risposto. Il motivo per cui il mio amico sta ponendo questa domanda è che è un momento perfetto nel ciclo di vita dei progetti per fare una recensione. Far accelerare gli assistenti di ricerca in Fortran richiede tempo (mi piace C #, in particolare gli strumenti e non riesco a immaginare di tornare alle lingue più vecchie !!)

Mi è piaciuto il suggerimento di mantenere scricchiolante il numero puro in Fortran, ma di inserirlo in qualcosa di più nuovo. Forse Python sembra che stia diventando una roccaforte nel mondo accademico come un linguaggio di programmazione generico che è abbastanza facile da imparare.

Vedi Medical Imaging e un ragazzo che ha scritto un wrapper Fortran per CUDA, posso pubblicare legalmente i miei wrapper Fortran 90 nella libreria CUFFT di Nvidias (dall'SDK CUDA)? .


Vorrei aggiungere OpenCL all'elenco.
Jerry Coffin,

3
Ciao Dave, c'è un certo tipo di "Quale lingua dovrei imparare dopo?" domanda che non consentiamo qui, quindi ho apportato piccole modifiche per assicurarmi che le persone non confondano questa domanda per quello. Ma puoi espandere la tua domanda per spiegare perché le scelte che hai scoperto finora non sono adatte, quindi può guidare le risposte per fornire una soluzione migliore?

Cosa intendi specificamente sotto "Può funzionare su diverse infrastrutture senza ricompilare"?
Rook,

Ciao @Idigas - non sono troppo sicuro dei dettagli. Ma essenzialmente la storia narra che quando si portava la base di codice ad altri cluster / macchine stava diventando un incubo ottenere tutte le versioni corrette delle librerie da compilare insieme. Credo che il codebase sia stato portato da F77 a F90 o qualsiasi altra cosa. Fondamentalmente sto cercando di aiutarlo a parlare con le persone giuste per prendere una decisione intelligente se cambiare architetture / lingue. Vengo da uno sfondo in cui ai clienti non piace un giorno di tempo di programmazione aggiuntivo, quindi tutto ciò che posso fare per aiutarmi a scrivere il miglior codice possibile il più veloce è l'ideale :-)
Dave Mateer,

@DaveMateer - Vedi la mia risposta (non si adattava a questo riquadro qui). Adesso vado a dormire, quindi le risposte future potrebbero essere un po 'lente :)
Rook,

Risposte:


24

Le richieste che hai posto in realtà mettono Fortran in cima alla lista, per problemi come questo:

a) numero scricchiolante
b) paralellabile
c) era ed è ancora la lingua di fatto insegnata al di fuori degli studi cs (agli ingegneri che non sono programmatori professionisti).
d) ha un incredibile (!) sostegno del settore, per quanto riguarda il numero di compilatori di livello industriale, con nessuno dei venditori che mostra i minimi segni di abbandono di quel ramo. Uno dei rappresentanti di Intel non molto tempo fa ha rivelato che le vendite dei loro prodotti Fortran sono superiori a qualsiasi altra nei loro strumenti di sviluppo.

È anche una lingua che è incredibilmente facile da imparare. Non sono d'accordo sul fatto che ci vuole tempo per accelerare gli assistenti di ricerca. Il mio primo libro di testo non conteneva più di, oh, non lo so, 30 (?) Pagine di testo stampato sparse. È una lingua in cui dopo aver appreso 10 parole chiave, si possono scrivere programmi di medie dimensioni. Oserei dire che quelle 30 pagine scritte nel testo predefinito di Word renderebbero un "manuale Fortran" più completo per la maggior parte degli utenti.

Se sei interessato a CUDA, potresti voler controllare il compilatore di Portland Group , che lo supporta . Non ho familiarità con i dettagli più fini, ma la gente generalmente ne parla con lode.

A parte questo, per i programmi in parallelo hai a disposizione OpenMP, MPI e ora i prossimi (e tanto attesi) co-array, che il compilatore Intel ha recentemente implementato. Per non sprecare parole, Fortran ha una gamma molto fine di "librerie" per parallelizzare i programmi.

Le librerie numeriche standard del settore sono sviluppate principalmente per questo, altre lingue seguono più o meno nel portafoglio funzioni / routine.

Detto questo, consiglierei comunque (dipende da quando è stato scritto in origine) se diciamo, codice F77 o precedente, riscrivendolo parzialmente nel tempo a dialetti più recenti - almeno F90, se possibile con le funzionalità F2003. Di recente è stato pubblicato un documento / tesi sull'argomento (file PDF di medie dimensioni in anticipo). Non solo ciò, se fatto correttamente, garantisce la portabilità su più piattaforme, ma renderà anche più facile la manutenzione futura.

ps Per quanto riguarda la "manutenzione futura", solo un aneddoto che a volte mi piace menzionare. Mentre scrivevo la mia tesi, ho riutilizzato un po 'di codice dal mio mentore, scritto 35 anni fa dal momento in cui ho scritto. Si è compilato con un solo errore; una dichiarazione mancante alla fine, a causa di un errore di copia incolla :)


@DaveMateer (risposta al commento) - Farò un commento nel seguito che può essere un po 'scortese, ma per favore non prenderlo nel modo sbagliato, perché è nelle giuste intenzioni.

Mi sembra che tu stia affrontando questo "problema" in modo sbagliato. Cosa intendo in alcuni punti brevi (perché è molto tardi qui, e la mia capacità di inventare frasi leggibili (per non parlare comprensibili) mi lascia dopo le 22:00)

a) hai detto che stai cercando di ridurre al minimo i tempi di codifica aggiuntivi, ma stai prendendo in considerazione una riscrittura da una lingua specializzata in calcolo numerico a una da una scelta colorata di lingue , se perdonerai la mia espressione

  • alcuni dei quali non supportano matrici multidimensionali, tra le altre cose
  • la maggior parte di questi non è adatta per lavori numerici pesanti (ammetto che Haskell e Hadoop hanno capacità di elaborazione parallele, non ne so nulla ... ma non li ho mai sentiti menzionati nemmeno in quegli ambienti)
  • forse è stato provato, ma non ho mai sentito parlare di una riscrittura da Fortran, un linguaggio per problemi discretizzati, in un linguaggio funzionale
  • recentemente c'è stata una discussione su comp.lang.fortran (prova a cercare tra i gruppi di google) sugli aspetti dell'informatica scientifica "nel cloud"
    (non mi piacerebbe de-motivarti, ma ad essere onesti, nessuno era davvero sicuro di ciò che quel termine rappresenti, meno da solo ha avuto un esempio di un'applicazione di successo. La maggior parte delle persone ha concordato che esiste il potenziale, ma finora sono felici del modo in cui le cose funzionano per ora.). Molti problemi non sono adatti nemmeno per quel tipo di parallelizzazione.

b) quali sarebbero i costi di tale riscrittura? persone / ora.

c) -corretta versione delle librerie da compilare ...- è un problema in qualsiasi lingua, che non può essere evitato, comunque tu lo guardi.

d) Ho sentito parlare di Python (un bel linguaggio davvero) usato in applicazioni parallele in alcune occasioni, ma la sua penetrazione in quel mercato non sembra ancora essere in aumento, e la sua natura in continua evoluzione lo rende una scelta molto scarsa per un progetto a lungo termine (pensa alla retrocompatibilità). Ad alcune persone piace molto come un linguaggio "colla".

Se penso a qualcos'altro, lo aggiungerò domani. Devo dormire un po '...


@Idigas .. molto apprezzato di nuovo. Sono totalmente d'accordo sul fatto che una volta che qualcosa funziona, significa molto. La nostra industria è piena di riscritture totali che vanno terribilmente male (Netscape!).
Dave Mateer,

1
Idigas ha avuto l'idea giusta qui. Hai una base di codice funzionante che funziona da anni e trascriverla genererà bug. Inoltre Fortran è un linguaggio semplice da imparare, potrebbe essere brutto ma è fatto da concetti chiari. Tieni sotto controllo le dipendenze da / verso un altro codice e magari scrivi una buona interfaccia in stile C su Fortran e troverai il codice per essere straordinariamente a prova di futuro (stile C poiché quasi ogni altra lingua là fuori ha un meccanismo da chiamare codice con un'interfaccia di tipo C).
anon

2
Devo essere d'accordo. Se capisci la matematica dietro ciò che stai facendo (e la maggior parte degli ingegneri fa), implementarla in FORTRAN non è una curva di apprendimento così ripida. Una volta creato, i requisiti cambieranno raramente come potrebbero accadere nelle app aziendali o social.
JeffO,

Wow, non sapevo che ci fosse così tanto amore per FORTRAN. Ho dovuto sviluppare in F77 per 5 anni e non sopporto.
dodgy_coder il

2
@dodgy_coder. È bello sapere che hai sviluppato in Fortran + .NET negli anni Novanta. La prima beta di .NET uscì nel 2000.

10

Dubito che Fortran morirà mai - ha una così grande eredità di software e librerie scritte che la gente ci sta ancora lavorando, stabilizzando solo questa situazione. Inoltre è ancora un linguaggio molto buono se non vuoi fare altro che scricchiolare i numeri: la sintassi è molto elegante e logica, inoltre il compilatore può facilmente indovinare cosa sta succedendo. Quindi è garantito che qualsiasi nuova tecnologia di accelerazione hardware supporterà C, Fortran e una sorta di OpenCL (quando alla fine converrebbe in qualcosa di solido).

Quindi direi che dovresti semplicemente separare chiaramente la parte numerica, lasciarla in Fortran, rendere chiara la rilegatura e scrivere il resto in qualsiasi cosa tu voglia.


Per non parlare del fatto che anche nuovi progetti a Fortran sono iniziati al giorno d'oggi.
Torre

Sì, Fortran non è COBOL, non è supportato solo perché è quello che la gente ha imparato 30 anni fa (anche se l'IMO ne fa parte). Lo scricchiolio dei numeri non è il mio punto forte, quindi se c'è di meglio non lo so di certo.
Ben Brocka,

1
La lingua fortran ha ancora un vantaggio di dieci anni sullo scricchiolio dei numeri e sulle ottimizzazioni associate. Non morirà presto.
Martin York,

1
L'articolo è apparso in una recente "Comunicazione dell'ACM" su Fortran e su come continua ad andare avanti e avanti con successive ammodernamenti. Mantenere (almeno la parte che scricchiola il numero) del codice in Fortran sarebbe probabilmente una buona mossa. Aiuta anche a evitare la sindrome di Netscape (riscrivi = nuovi bug = enorme tempo di ciclo = incazzato da tutti i soggetti coinvolti).
quick_now

1
Vuoi davvero che qualcuno che non sia affatto interessato a Fortran tocchi il tuo codice di scricchiolio numero? Un grosso problema è assicurarsi che il risultato sia ancora accurato dopo una riscrittura.
Peter Smith,

4

Python sta effettivamente guadagnando molta trazione nella comunità informatica scientifica (per una visione un po 'datata, vedi volume 9 numero 3 di CiSE ). Penso che un ibrido Python / Fortran sia un ottimo modo di procedere. Per sfruttare tutte queste GPU, è possibile utilizzare PyCUDA o PyOpenCL .

Sono un matematico che analizza e scrive solutori numerici per equazioni differenziali parziali. Di recente mi sono trovato in una situazione simile a quella del tuo amico; il codice Fortran 77 in questione è il noto software Clawpack . Abbiamo riscritto il codice di livello superiore (tutte le parti che non hanno bisogno di essere veloci) in Python e abbiamo usato f2py per avvolgere automaticamente le parti di basso livello.

Il risultato davvero potente di questo è che siamo stati quindi in grado di collegare quasi banalmente il codice ibrido Python / Fortran (soprannominato PyClaw ) con la libreria parallela PETSc, creando per la prima volta una versione parallela scalabile di Clawpack che funziona bene su core 65K. Tutto il codice parallelo che abbiamo dovuto scrivere è contenuto in meno di 300 righe di Python . Ora stiamo risolvendo problemi che non avrebbero potuto essere affrontati solo con il codice legacy. Altrettanto importante, ora è molto più facile per i nuovi utenti raccogliere il codice, poiché Python è un linguaggio così amichevole e quasi tutto può essere modificato in fase di esecuzione anziché in fase di compilazione.

Se vuoi vedere maggiori dettagli sul nostro approccio e sui nostri risultati, abbiamo un articolo su arXiv .

Ci scusiamo per l'auto-pubblicità, ma sembrava che la mia esperienza personale sarebbe stata rilevante qui. Se desideri ascoltare molte altre idee, puoi pubblicarlo anche sul nuovo http://scicomp.stackexchange.com .


1

Attualmente mi trovo in una situazione molto simile a quella del tuo amico. Sono anche alla disperata ricerca di "modernizzare" il mio codice legacy KLOC Fortran-77 da 40 elementi. E nonostante il fatto che Fortran sia ancora considerato il re nelle applicazioni di scricchiolio del numero, vorrei dire che non tutto è perduto. (Quello che segue è rant-ish quindi abbiate pazienza con me).

Solo perché Fortran è la lingua migliore per il codice numerico non significa che dobbiamo portare sempre con noi questo enorme bagaglio di un codice disordinato e complicato (Sì, un codice Fortran è destinato a essere disordinato, in particolare Fortran-77 che è un linguaggio che non ha letteralmente alcun riguardo per l'ingegneria del software, quando attraversa un certo KLOC). Coloro che sostengono Fortran per il crunching dei numeri dimenticano l'osservazione generale che quando si esegue l'analisi delle prestazioni di tali codici, è solo il 5% o il 10% del codice che è ad alte prestazioni e per il restante 90% + Fortran è un sovraccarico inutile, solo lì per rendere la tua vita di "ingegnere del software" un inferno vivente.

Quando ti trasferisci a Fortran-90 da Fortran-77, sei essenzialmente disposto a bilanciare le prestazioni con le funzionalità linguistiche in una certa misura. Fortran è un potente cruncher numerico principalmente a causa di Fortran-77. Potresti dire che Fortran-90 è il più veloce, ma il tipo di problemi di ottimizzazione che gli autori di compilatori hanno dovuto affrontare mentre aggiungevano le funzionalità di Fortran-90/2003 e mantenendo le prestazioni di Fortran-77 non sono molto diversi dai problemi che gli autori di compilatori C dovevano affrontare con (e di conseguenza anche C è considerato veloce, per non parlare di C che consente anche l'assemblaggio in linea). Quindi, perché non iniziare ad aggiungere il codice C bit per bit (invece di Fortran-90) in un codice Fortran-77. Il mio codice ha già pezzi in C e pezzi in Fortran-77 e funziona benissimo con alcuni problemi come il passaggio di stringhe, zero-indicizzazione / one-indicizzazione ecc. Ma il vantaggio che ottengo da C,

Farei un ulteriore passo avanti. Anche C (e sicuramente Fortran-90/95/2003) è di livello troppo basso se si desidera un'interfaccia "umana" per un codice numerico. Sto pensando di passare a un Python-Fortran-77 o un ibrido Python-C. Un codice in cui il 90% del codice è Python (compresi Numpy, Scipy, la trama e tutta quella dolcezza) e solo il 5% -10% ad alta intensità di prestazioni rimane come codice Fortran-77 o C.


1
"un codice Fortran è destinato a essere disordinato". No. Un programmatore disordinato scriverà codice disordinato in qualsiasi lingua e il contrario è vero. Kernighan e Plauger hanno dimostrato anni fa come scrivere pulito Fortran .

0

Attualmente sto aggiornando una vecchia base di codice FORTRAN95 da utilizzare in ambienti industriali moderni poiché la versione precedente verrà eseguita solo su macchine Windows 2000 al più tardi. La base di codice FORTRAN stessa esegue una grande quantità di scricchiolii numerici coinvolti nelle simulazioni di irrigazione.

Quindi quello che sto facendo è invece di riscrivere FORTRAN in un linguaggio più moderno, sto semplicemente usando un compilatore commerciale chiamato Silverfrost FTN95 per compilare la base di codice FORTRAN in una libreria .Net 4.0 che sto usando come backend di un'applicazione WPF . In questo modo non corro il rischio di introdurre bug noti nel codice di simulazione e lo sto modernizzando spostando la base di codice nel framework .Net 4.0 in modo che possa funzionare in ambienti più moderni.

Ma a seconda di quanto sia grande la tua simulazione potresti voler semplicemente riscrivere il tutto in un linguaggio più moderno come C #, io stesso sto programmando di farlo una volta che avrò una versione in esecuzione della simulazione con cui confrontare l'output.

Spero che la mia esperienza mi aiuti, grazie Alex.


0

Sono stato responsabile dello sviluppo di un progetto dal 2001 al 2003 che ha portato un'applicazione Windows 100KLOC da FORTRAN a C #. Era un'applicazione che riduceva il numero e aveva i propri collegamenti della GUI personalizzati alle librerie Win32. La porta su C # e WinForms ha reso la gestione del codice molto più semplice e ha dato a tutti un ambiente di sviluppo più ricco in Visual Studio. All'inizio c'era un bel po 'di resistenza (specialmente in termini di dichiarazioni di formato), ma alla fine ne è valsa decisamente la pena.

Secondo me ha senso mordere il proiettile e sbarazzarsi della massima quantità di codice FORTRAN possibile. La velocità non è mai stata un problema: i test iniziali che eseguono il codice in C # rispetto a FORTRAN hanno riscontrato che la differenza di prestazioni è trascurabile, anche se C # esegue il codice gestito. Tuttavia, le tue esigenze con i vettori potrebbero essere leggermente diverse, e avere anche una minoranza di codice FORTRAN lasciato sarebbe accettabile.

Un altro motivo per farlo è ovviamente la disponibilità a lungo termine di persone con esperienza FORTRAN in grado di mantenere il codice rispetto agli sviluppatori C #. Inoltre, aiuta il morale della squadra a lavorare in un linguaggio moderno e ben supportato.


0

Mi è stato detto che in molti contesti, MATLAB sta sostituendo FORTRAN per l'applicazione di calcolo scientifico. Non solo è moderno e di alto livello, ma è anche piuttosto veloce in quello che fa. Molti sviluppatori che lavorano su software di imaging medico utilizzano già MATLAB, quindi ha diverse librerie dedicate all'immaginazione medica. Ciò significa che troverai MATLAB sia per gli strumenti che per il supporto di esperti di dominio.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.