Domanda

Recentemente sono arrivato a mantenere una grande quantità di codice FORTRAN ad alta intensità di calcoli scientifici.Ho difficoltà a comprendere tutte, diciamo, le sfumature di una lingua vecchia di quarant'anni, nonostante Google e due libri di livello introduttivo.Il codice è pieno di "miglioramenti che migliorano le prestazioni".Qualcuno ha qualche guida o consiglio pratico per de-ottimizzare FORTRAN nei livelli CS 101?Qualcuno sa come funziona l'ottimizzazione del codice FORTRAN?Esistono dei tipici "trucchi" FORTRAN che potrebbero non venire in mente a uno sviluppatore cresciuto in Java/C++/.NET che assume il controllo di una base di codice FORTRAN 77/90?

È stato utile?

Soluzione

In un certo senso devi avere un'idea di ciò che i programmatori dovevano fare in passato.La stragrande maggioranza del codice con cui lavoro è più vecchio di me e funzionava su macchine che erano "nuove" quando i miei genitori erano al liceo.

Gli ismi FORTRAN comuni di cui mi occupo e che danneggiano la leggibilità sono:

  • Blocchi comuni
  • Variabili implicite
  • Due o tre cicli DO con istruzioni CONTINUE condivise
  • GOTO è al posto dei loop DO
  • Istruzioni aritmetiche IF
  • GOTO calcolati
  • Equivalenza REALE/INTERO/altro in qualche blocco comune

Le strategie per risolverli implicano:

  1. Ottenere Spag / plusFORT, vale la spesa, ne risolve molti automaticamente e senza bug(tm)
  2. Passare a Fortran 90 se possibile, altrimenti passare a Fortran 77 in formato libero
  3. Aggiungi IMPLICIT NONE a ciascuna subroutine e quindi correggi ogni errore di compilazione, dispendioso in termini di tempo ma in definitiva necessario, alcuni programmi possono farlo automaticamente (oppure puoi crearlo tramite script)
  4. Spostare tutti i blocchi COMUNI nei MODULI, ne vale la pena
  5. Converte istruzioni aritmetiche IF in blocchi IF..ELSEIF..ELSE
  6. Converti i GOTO calcolati in blocchi SELECT CASE
  7. Converti tutti i loop DO nella più recente sintassi F90

    myloop: do ii = 1, nloops
        ! do something
    enddo myloop
    
  8. Converti i membri del blocco comune equivalenti in memoria ALLOCATABLE allocata in un modulo o nelle loro routine di caratteri reali se si tratta di Hollerith memorizzato in un REAL

Se avessi domande più specifiche su come eseguire alcune attività di leggibilità, posso darti consigli.Ho una base di codice di poche centinaia di migliaia di righe di Fortran che è stata scritta nell'arco di 40 anni di cui sono in qualche modo responsabile, quindi probabilmente ho riscontrato eventuali "problemi" che potresti aver riscontrato.

Altri suggerimenti

Soapbox Fortran legacy

Ho contribuito a mantenere/migliorare una base di codice Fortran legacy per un bel po' e per la maggior parte ho pensato variabili di sei lettere è in denaro.Questo consiglio, però, tende al tecnico;una battaglia più dura da affrontare è nell'implementazione delle "buone pratiche".

  • Stabilire lo stile di codifica richiesto e le linee guida per la codifica.
  • Richiedere una revisione del codice (non solo del programmatore!) per qualsiasi cosa inviata alla codebase.(Il controllo della versione dovrebbe essere legato a questo processo.)
  • Iniziare a creare ed eseguire unit test;idem test di benchmark o di regressione.

Potrebbero sembrare cose ovvie al giorno d'oggi, ma a rischio di generalizzare eccessivamente, sostengo che la maggior parte dei negozi di codici Fortran hanno una cultura radicata, alcuni sono iniziati prima ancora che esistesse il termine "ingegneria del software", e che nel tempo ciò che arriva a dominare è "Fallo adesso".(Questo non è in alcun modo esclusivo dei negozi Fortran.)

Abbracciando i Gotchas

Ma cosa fare con una base di codice legacy già esistente e scadente?Sono d'accordo con Joel Spolsky sulla riscrittura, non.Tuttavia, secondo me variabili di sei lettere indica l'eccezione consentita: Utilizza strumenti software per passare a costrutti Fortran migliori. Molto può essere catturato/corretto dagli analizzatori di codice (PERVERIFICARE) e riscrittori di codice (piùFORTE).Se devi farlo a mano, assicurati di avere un motivo urgente.(Vorrei avere a portata di mano un riferimento al numero di bug del software derivanti dalla correzione dei bug del software, è umiliante.Penso che una statistica del genere esista Programmazione C esperta.)

Probabilmente il miglior attacco per vincere il gioco dei trucchi Fortran è avere la migliore difesa:Conoscere abbastanza bene la lingua.A tal fine, consiglio...libri!

Biblioteca dell'albero morto di Fortran

Nel corso degli anni ho avuto solo un modesto successo come "ronzino del controllo qualità", ma ho scoperto che l'istruzione funziona, a volte inavvertitamente, e che una delle cose più influenti è un libro di consultazione che qualcuno ha a portata di mano.Adoro e lo consiglio vivamente

Fortran 90/95 per scienziati e ingegneri, di Stephen J.Chapmann

Il libro è valido anche con Fortran 77 in quanto identifica specificamente i costrutti che non dovrebbero essere utilizzati e fornisce le alternative migliori.Tuttavia, in realtà è un libro di testo e può esaurirsi quando vuoi davvero conoscere i noccioli di Fortran 95, motivo per cui lo consiglio

Fortran 90/95 spiegato, di Michael Metcalf e John K.Reid

come riferimento (sic) per Fortran 95.Tieni presente che non è la scrittura più lucida, ma il velo si solleverà quando vorrai davvero ottenere il massimo da una nuova funzionalità Fortran 95.

Mi sono divertito a concentrarmi sui problemi del passaggio da Fortran 77 a Fortran 90

Migrazione a Fortran 90, di Jim Kerrigan

ma il libro è ormai fuori stampa.(Semplicemente non capisco l'uso che O'Reilly fa di Safari, perché non sono disponibili tutti i loro libri fuori stampa?)

Infine, per quanto riguarda l'erede del meraviglioso, meraviglioso classico, Strumenti software, nomino

FORTRAN classico, di Michael Kupferschmid

Questo libro non solo mostra cosa si può fare con "solo" Fortran 77, ma parla anche di alcuni dei problemi più sottili che sorgono (ad esempio, si dovrebbe o non si dovrebbe usare la dichiarazione EXTERNAL).Questo libro non copre esattamente lo stesso spazio di "Strumenti software" ma sono due dei tre libri di programmazione Fortran che etichetterei come "divertenti"....(ecco il terzo).

Varie Consigli applicabili a Quasi ogni compilatore Fortran

  • Esiste un'opzione del compilatore per imporre il comportamento IMPLICIT NONE, che è possibile utilizzare per identificare le routine problematiche senza prima modificarle con la dichiarazione IMPLICIT NONE.Questo consiglio non sembrerà significativo fino a dopo la prima volta che una build fallisce a causa di un comando IMPLICIT NONE inserito in una routine legacy.(Che cosa?La tua revisione del codice non ha rilevato questo problema?;-)
  • Esiste un'opzione del compilatore per il controllo dei limiti dell'array, che può essere utile durante il debug del codice Fortran 77.
  • I compilatori Fortran 90 dovrebbero essere in grado di compilare quasi tutto il codice Fortran 77 e anche il codice Fortran più vecchio.Attiva le opzioni di reporting sul tuo compilatore Fortran 90, esegui il tuo codice legacy e avrai un buon inizio con il controllo della sintassi.Alcuni compilatori Fortran 77 commerciali sono in realtà compilatori Fortran 90 che funzionano in modalità Fortran 77, quindi questa potrebbe essere un'opzione relativamente banale da modificare per qualunque script di build tu abbia.

C'è qualcosa nella domanda originale su cui vorrei mettere in guardia.Dici che il codice è pieno di "miglioramenti che migliorano le prestazioni".Poiché i problemi Fortran sono generalmente di natura scientifica e matematica, non dare per scontato che questi trucchi prestazionali servano a migliorare la compilazione.Probabilmente non è questione di lingua.In Fortran, la soluzione raramente riguarda l'efficienza del codice stesso, ma la matematica sottostante per risolvere il problema finale.I trucchi possono rallentare la compilazione, possono anche far sembrare confusa la logica, ma l'intento è quello di rendere la soluzione più veloce.A meno che tu non sappia esattamente cosa sta facendo e perché, lascialo stare.

Anche il semplice refactoring, come cambiare nomi di variabili dall'aspetto stupido, può essere una grossa trappola.Le equazioni matematiche storicamente standard in un dato campo della scienza avranno utilizzato una particolare abbreviazione sin dai tempi di Maxwell.Quindi vedere un array chiamato B(:) in elettromagnetismo dice a tutti gli ingegneri di Emag esattamente per cosa si sta risolvendo.Cambialo a tuo rischio e pericolo.Morale, conoscere la nomenclatura standard della scienza prima di rinominarla.

Essendo qualcuno con esperienza sia in FORTRAN (sapore 77 anche se è passato un po' di tempo dall'ultima volta che lo uso seriamente) che in C/C++, l'elemento a cui prestare attenzione che mi viene subito in mente sono gli array.Gli array FORTRAN iniziano con un indice pari a 1 anziché 0 come in C/C++/Java.Inoltre, la disposizione della memoria è invertita.Quindi incrementando il primo indice si ottengono posizioni di memoria sequenziali.

Mia moglie usa ancora FORTRAN regolarmente e ha del codice C++ con cui deve lavorare ora che sto per iniziare ad aiutarla.Man mano che emergono problemi durante la sua conversione, cercherò di evidenziarli.Forse aiuteranno.

Potresti spiegare cosa devi fare per mantenere il codice?È davvero necessario modificare il codice?Se riesci a farla franca modificando solo l'interfaccia di quel codice invece del codice stesso, sarebbe la cosa migliore.

Il problema intrinseco quando si ha a che fare con un codice scientifico di grandi dimensioni (non solo FORTRAN) è che la matematica sottostante e l'implementazione sono entrambe complesse.Quasi per impostazione predefinita, l'implementazione deve includere l'ottimizzazione del codice, al fine di essere eseguito entro un periodo di tempo ragionevole.Ciò è aggravato dal fatto che gran parte del codice in questo campo viene creato da scienziati/ingegneri esperti nel loro campo, ma non nello sviluppo di software.Diciamo solo che "facile da capire" non è la prima priorità per loro (ero uno di loro, stavo ancora imparando a diventare uno sviluppatore di software migliore).

A causa della natura del problema, non credo che una domanda e una risposta generale siano sufficienti per essere utili.Ti suggerisco di pubblicare una serie di domande specifiche con lo snippet di codice allegato.Magari iniziando da quello che ti dà più mal di testa?

Ho usato Fortran a partire dalla versione '66 dal 1967 (su un IBM 7090 con 32k parole di memoria).Poi ho usato PL/1 per un po' di tempo, ma poi sono tornato al Fortran 95 perché è ideale per i problemi di matrici/numeri complessi che abbiamo.Vorrei aggiungere alle considerazioni che gran parte della struttura contorta dei vecchi codici è semplicemente dovuta alla piccola quantità di memoria disponibile, costringendo a cose come riutilizzare alcune righe di codice tramite calcoli o assegnazioni GOTOS.Un altro problema è l'ottimizzazione definendo variabili ausiliarie per ogni sottoespressione ripetuta: i compilatori semplicemente non hanno ottimizzato per questo.Inoltre, non era consentito scrivere DO i=1,n+1;dovevi scrivere n1=n+1; DO i=1,n1.Di conseguenza i vecchi codici sono sommersi da variabili superflue.Quando ho riscritto un codice in Fortran 95, solo il 10% delle variabili è sopravvissuto.Se vuoi rendere il codice più leggibile, ti consiglio vivamente di cercare variabili che possano essere facilmente eliminate.

Un'altra cosa che potrei menzionare è che per molti anni gli array aritmetici complessi e multidimensionali sono stati altamente inefficienti.Questo è il motivo per cui spesso trovi codice riscritto per eseguire calcoli complessi utilizzando solo variabili reali e matrici indirizzate con un singolo indice lineare.

Beh, in un certo senso sei fortunato, perché Fortran non ha molto in termini di sottili costrutti di flusso di controllo o ereditarietà o simili.Dall'altro, ha alcuni trucchi davvero sorprendenti, come il materiale da ramo a etichetta numerica calcolato aritmeticamente, le variabili tipizzate implicitamente che non richiedono dichiarazione, la mancanza di parole chiave vere.

Non conosco i "miglioramenti di miglioramento delle prestazioni".Immagino che la maggior parte di essi sia probabilmente inefficace, poiché un paio di decenni di tecnologia dei compilatori hanno reso superflui la maggior parte dei suggerimenti.Sfortunatamente, probabilmente dovrai lasciare le cose come sono, a meno che tu non abbia intenzione di fare una riscrittura massiccia.

In ogni caso, il codice di calcolo scientifico di base dovrebbe essere abbastanza leggibile.Qualsiasi linguaggio di programmazione che utilizzi l'aritmetica infissa sarebbe una buona preparazione per leggere l'aritmetica e il codice di assegnazione di Fortran.

Amavo FORTRAN, lo insegnavo e lo codificavo.Volevo solo inserirlo.Non lo tocco da anni.
Ho iniziato in COBOL, quando mi sono trasferito in FORTRAN mi sono sentito liberato.Tutto è relativo, vero?Condivido ciò che è stato detto sopra - riconosco che questo è un linguaggio PROCEDURALE - senza sottigliezze - quindi prendilo come lo vedi.
Probabilmente ti frustra tanto per cominciare.

Ho iniziato con Fortran IV (WATFIV) su schede perforate e i miei primi anni di lavoro sono stati VS FORTRAN v1 (IBM, livello Fortran 77).Tanti buoni consigli in questo thread.

Vorrei aggiungere che devi distinguere tra le cose fatte per far funzionare la bestia, rispetto alle cose che "ottimizzano" il codice, rispetto alle cose che sono più leggibili e gestibili.Ricordo di aver avuto a che fare con gli overlay VAX nel tentativo di far funzionare il codice di simulazione DOE su IBM con memoria virtuale (dovevano essere rimossi e il tutto trasformato in uno spazio di indirizzi).

Inizierei sicuramente ristrutturando attentamente le strutture di controllo FORTRAN IV almeno al livello FORTRAN 77, con rientro e commenti adeguati.Cerca di sbarazzarti delle strutture di controllo primitive come ASSIGN e COMPUTED GOTO e l'aritmetica IF e, ovviamente, quanti più GOTO puoi (usando IF-THEN-ELSE-ENDIF).Sicuramente usa IMPLICIT NONE in ogni routine, per forzarti a dichiarare correttamente tutte le variabili (non crederesti quanti bug ho riscontrato nel codice di altre persone - errori di battitura nei nomi delle variabili).Fai attenzione alle "ottimizzazioni premature" che è meglio lasciare che il compilatore gestisca da solo.

Se questo codice vuole continuare a vivere ed essere mantenibile, è vostro dovere, nei confronti di voi stessi e dei vostri successori, renderlo leggibile e comprensibile. Assicurati solo di quello che stai facendo mentre modifichi il codice! FORTRAN ha molti costrutti particolari che possono facilmente inciampare qualcuno che proviene dal lato C del mondo della programmazione.Ricorda che FORTRAN risale alla metà della fine degli anni '50, quando non esisteva una scienza del linguaggio e della progettazione di compilatori, solo ad hoc mettere insieme qualcosa (scusa, Dr.B!).

Eccone un altro che mi ha morso di tanto in tanto.Quando lavori sul codice FORTRAN assicurati di saltare tutte e sei le colonne iniziali.Di tanto in tanto, ricevo solo il codice rientrato di cinque spazi e non funziona nulla.A prima vista sembra tutto a posto e poi finalmente mi rendo conto che tutte le righe iniziano nella colonna 6 invece che nella colonna 7.

Per chiunque non abbia familiarità con FORTRAN, le prime 5 colonne sono per i numeri di riga (= etichette), la sesta colonna è per un carattere di continuazione nel caso in cui tu abbia una riga più lunga di 80 caratteri (basta inserire qualcosa qui e il compilatore saprà che questa riga fa effettivamente parte di quello precedente) e il codice inizia sempre nella colonna 7.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top